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ABSTRACT 


Traditionally, the design and implementation of a conventional database 
system begins with the selection of a data model, followed by the specification of 
a model-based data language. An alternative to this traditional approach to 
database system development is the multi-lingual database system (MLDS). This 
alternative approach affords the user the ability to access and manage a large 
collection of databases via several data models and their corresponding data 
languages. 

In this thesis we present the specification and implementation of a network 
CODASYL-DML language interface for the MLDS. Specifically, we present the 
specification and implementation of an interface which translates CODASYL- 
DML data language calls into attribute-based data language (ABDL) requests. 
We describe the software engineering aspects of our implementation and an 
overview of the four modules which comprise our CODASYL-DML language 


interface. 
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I. INTRODUCTION 


À. MOTIVATION 

During the past twenty years database systems have been designed and 
implemented using what we refer to as the traditional approach. The first step in 
the traditional approach involves choosing a data model. Candidate data models 
include the hierarchical data model, the relational data model, the network data 
model, the entity-relationship data model, and the attribute-based data model to 
name a few. The second step specifies a model-based data language, e.g., DL/I 
for the hierarchical data model, or Daplex for the entity-relationship data model. 

A number of. database systems have been developed using this 
methodology. For example, IBM introduced the Information Management 
System (IMS) in the sixties, which supports the hierarchical data model and the 
hierarchical-model-based data language, Data Language I (DL/I). Sperry Univac 
introduced the DMS-1100 in the early seventies, which supports the network data 
model and the network-model-based data language, CODASYL Data 
Manipulation Language (CODASYL-DML). And more recently, there has been 
IBM’s introduction of the SQL/Data System which supports the relational model 
and the relational-model-based data language, Structured English Query 
Language (SQL). This traditional approach to database system development has 
resulted in homogeneous database systems that restrict the user to a single data 
model and a specific model-based data language. 

An unconventional approach to database system development, referred to 
as the Multi-lingual Database System (MLDS) |[Ref. 1], alleviates the 
aforementioned restriction. This new system affords the user the ability to access 
and manage a large collection of databases via several data models and their 
corresponding data languages. The design goals of MLDS involve developing a 
system that is accessible via a hierarchical/DL/I interface, a relational/SQL 
interface, a  network/CODASYL/DML interface, and an entity- 


relationship/Daplex interface. 
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There are a number of advantages in developing such a system. Perhaps 
the most practical of these involves the reusability of database transactions 
developed on an existing database system. In MLDS, there is no need for the 
user to convert a transaction from one data language to another. MLDS also 
permits the running of database transactions written in different data languages. 
Therefore, the user does not have to perform either manual or automated 
translation of existing transactions in order to execute a transaction in the 
MLDS. MLDS provides the same results even if the data language of the 
transaction originates at a different database system. 

A second advantage deals with the economy and effectiveness of hardware 
upgrade. Frequently, the hardware supporting the database system is upgraded 
because of technological advancements or system demand. With the traditional 
approach, this type of hardware upgrade has to be provided for all of the 
different database systems in use, so that all of the users may experience system 
performance improvements. This is not the case in MLDS, where only the 
upgrade of a single system is necessary. In MLDS, the benefits of a hardware 
upgrade are uniformly distributed across all users, despite their use of different 
models and data languages. 

Thirdly, a multi-lingual database system allows users to explore the 
desirable features of the different data models and then use these to better 
support their applications. This is possible because MLDS supports a variety of 
databases structured in any of the well-known data models. 

It is apparent that there exists ample motivation to develop a multi- 
lingual database system with many data model/data language interfaces. In this 
thesis, we are developing a network(CODASYL) language interface for the 
MLDS. We are extending the work of Banerjee [Ref. 2] and Wortherly [Ref. 3], 
who have shown the feasibility of this particular interface in a MLDS. 


B. THE MULTI-LINGUAL DATABASE SYSTEM 

A detailed discussion of each of the components of the MLDS is provided 
in subsequent chapters. In this section we provide an overview of the 
organization of MLDS. This assists the reader in understanding how the different 


components of MLDS are related. 
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Figure 1 shows the system structure of a multi-lingual database system. 
The user interacts with the system through the language interface layer (LIL), 
using a chosen user data model (UDM) to issue transactions written in a 
corresponding inodel-based user data language (UDL). The LIL routes the user 
transactions to the kernel mapping system (KMS). The KMS performs one of 
two possible tasks. First, the KMS transforms a UDM-based database definition 
to a database definition of the kernel data model (KDM), when the user specifies 
that a new database is to be created. When the user specifies that a UDL 
transaction is to be executed, the KMS translates the UDL transaction to a 
transaction in the kernel data language (KDL). In the first task, KMS forwards 
the KDM data definition to the kernel controller (KC). KC, in turn, sends the 





CDM serData Model 
CDE : User Data Language 


LIL : Language Interface Laver 
aS : Kernel Mapping System 
KC : Kernel Controller 

KFS : Kernel Formatting System 
KDM  : Kernel Data Model 

KDL : Kernel Data Language 
KDS : Kernel Database System 


Figure 1. The Multi-Lingual Database System. 
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KDM database definition to the kernel database system (KDS). When KDS is 
finished. with processing the KDM database definition, it informs the KC. KC 
then notifies the user, via the LIL, that the database definition has been 
processed and that loading of the database records may begin. In the second 
task, KMS sends the KDL transactions to the KC. When KC receives the KDL 
transactions, it forwards them to KDS for execution. Upon completion, KDS 
sends the results in KDM form back to the KC. KC routes the results to the 
kernel formatting system (KFS). KFS reformats the results from KDM form to 
UDM form. KFS then displays the results in the correct UDM form via LIL. 

The four modules, LIL, KMS, KC, and KFS, are collectively known as the 
language interface. Four similar modules are required for each of the other 
language interface of MLDS. For example, there are four sets of these modules 
where one set is for the hierarchical/DL/I language interface, one for the 
relational/SQL language interface, one for the network/CODASYL/DML 
language interface, and one for the entity-relationship/Daplex language interface. 
However, if the user writes the transaction in the native mode (i.e., in KDL), 
there is no need for an interface. 

In our implementation of the network(CODASYL) language interface, we 
develop the code for the four modules. However, we do not integrate these 
modules with KDS as shown in Figure 1. The Laboratory of Database Systems 
Research at the Naval Postgraduate School is in the process of procuring new 
computer equipment for KDS. When the equipment is installed, KDS is to be 
ported over to the new equipment. MLDS software is then to be integrated with 


KDS. Although not a very difficult undertaking, it may be time-consuming. 


C. THE KERNEL DATA MODEL AND LANGUAGE 

The choice of a kernel data model and a kernel data language is the key 
decision in the development of a multi-lingual database system. The overriding 
question, when making such a choice, is whether the kernel data model and 
kernel data language is capable of supporting the required data-model 
transformations and data-language translations for the language interfaces. 

The attribute-based data model proposed by Hsiao [Ref. 4], extended by 
Wong [Ref. 5], and studied by Rothnie [Ref. 6], along with the attribute-based 
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data language (ABDL), defined by Banerjee [Ref. 7], have been shown to be 
acceptable candidates for the kernel data model and kernel data language, 
respectively. 

Why is the determination of a kernel data model and kernel data language 
so important for a MLDS? No matter how multi-lingual MLDS may be, if the 
underlying database system (i.e., KDS) is slow and inefficient, then the interfaces 
may be rendered useless and untimely. Hence, it is important that the kernel 
data model and kernel language be supported by a high-performance and great- 
capacity database system. Currently, only the attribute-based data model and 
the attribute-based data language are supported by such a system. This system 
is the multi-backend database system (MBDS) [Ref. 1]. 


D. THE MULTI-BACKEND DATABASE SYSTEM 

The multi-backend database system (MBDS) has been designed to 
overcome the performance problems and upgrade issues related to the traditional 
approach of database system design. This goal is realized through the utilization 
of multiple backends connected in a parallel fashion. These backends have 
identical hardware, replicated software, and their own disk systems. In a 
multiple backend-configuration, there is a backend controller, which is responsible 
for supervising the execution of database transactions and for interfacing with the 
hosts and users. The backends perform the database operations with the 
database stored on the disk system of the backends. The controller and backends 
are connected by a communication bus. Users access the system through either 
the hosts or the controller directly (see Figure 2). 

Performance gains are realized by increasing the number of backends. If 
the size of the database and the size of the responses to the transactions remain 
constant, then MBDS produces a reciprocal decrease in the response times for the 
user transactions when the number of backends is increased. On the other hand, 
if the number of backends is increased proportionally with the increase in 
databases and responses, then MBDS produces invariant response times for the 


same transactions. A more detailed discussion of MBDS is found in [Ref. 8]. 
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Figure 2. The Multi-Backend Database System. 
E. THESIS OVERVIEW 


The organization of our thesis is as follows: In Chapter II, we discuss the 
software engineering aspects of our implementation. This includes a discussion of 
our design approach, as well as a review of the global data structures used for the 
implementation. In Chapter III, we outline the functionality of the language 
interface layer. In Chapter IV, we articulate the processes constituting the kernel 
Mapping system. In Chapter V, we provide an overview of the kernel controller. 
In Chapter VI, we describe the kernel formatting system. In Chapter VII, we 
conclude the thesis. 

The detailed specifications of the interface modules (i.e., LIL, KMS, and 
KC) are given in Appendices A, B, and C, respectively. Appendix D is a users’ 


manual for the system. The specifications of the source data language, 
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CODASYL-DML, and the target data language, ABDL, is found in 
[Ref. 9: pp. 389-446] and [Ref. 7], respectively. 

Throughout this thesis, we provide examples of CODASYL-DML requests 
and their translated ABDL equivalents. All examples involving database 
operations presented in this thesis are based on the Suppliers and Parts sample 
database used by Date [Ref. 9: pp. 389-446]. The data structure diagram for this 
network is shown in Figure 3. There are supplier records (S), parts records (P), 
and shipments (SP) records. The sets of the database are suppliers-shipments (S- 
SP) and parts-shipments (P-SP). 


S E 
e A m 4 4 
| suppliers | | parts | 
(eee + oe ee 4. 
{oat y 
SSP | P-SP | 
fee "er m 
SE 
y + 
| shipments | 
Pd g 


Figure 3. Data Structure Diagram of the Sample 
Suppliers-and-Parts Database. 
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II. SOFTWARE ENGINEERING OF A LANGUAGE INTERFACE 


In this chapter, we discuss the various software engineering aspects of 
developing a language interface. First, we describe our design goals. Second, we 
outline the design approach that we took to implement the interface. Included in 
this section are discussions of our implementation strategy, our software 
development techniques, and salient characteristics of the language interface 
software. Then, we provide a critique of our implementation. Fourth, we 
describe the data structures used in the interface. And finally, we provide an 


organizational description of the next four chapters. 


A. DESIGN GOALS 

We are motivated to implement a CODASYL-DML interface for a MLDS 
using MBDS as the kernel database system, the attribute-based data model as 
the kernel data model, and ABDL as the kernel data language. It is important 
to note that we do not propose changes to the kernel database system or 
language. Instead, our implementation resides entirely in the host computer. 
All user transactions in CODASYL-DML are processed in the CODASYL- 
DML interface. MBDS continues to receive and process requests in the syntax 
and semantics of ABDL. 

In addition, we intend to make our interface transparent to the user. For 
example, an employee in a corporate environment with previous experience 
with CODASYL-DML could log onto our system, issue a CODASYL-DML 
request and receive result data in a network format, i.e., a record. The 
employee requires no training in ABDL or MBDS procedures prior to utilizing 


the system. 


B. AN APPROACH TO THE DESIGN 
1. “The Implementation Strategy 


There are a number of different strategies we might have employed in 


the implementation of the CODASYL-DML language interface. For example, 
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there are the build-it-twice full-prototype approach, the level-by-level top-down 
approach, the incremental development approach, and the advancemanship 
approach [Ref. 10: pp. 41-46]. We have predicated our choice on minimizing 
the "software-crisis" as explained by Boehm [Ref. 10: pp. 14-31]. 

The strategy we have decided upon is the level-by-level top-down 
approach. Our choice is based on, first, a time constraint. The interface has 
to be developed within a specified time, specifically, by the time we 
graduate. And second, this approach lends itself to the natural evolution of 
the interface. The system is initially thought of as a "black box" (see Figure 1) 
that accepts CODASYL-DML transactions and then returns the appropriate 
results. The "black box" is then decomposed into its four modules (i.e., 
LIL, KMS, KC, and KFS). These modules, in turn, are further decomposed 
into the necessary functions and procedures to accomplish the appropriate 
tasks. 

2. Techniques for Software Development 

In order to achieve our design goals, it is important to employ 
effective software engineering techniques during all phases of the software 
development life-cycle. These phases, as defined by Ledthrum [Ref. 11: p. 27], 
are as follows: 


(1) Requirements Specification - This phase involves stating the purpose of 
the software: what is to be done, not how it is to be done. 


(2) Design - During this pes an algorithm is devised to carry out the 
specification produced in the previous phase. That is, how to 
implement the system which is specified during this phase. 


(3) Coding - During this phase the design is translated into a programming 
language. 


(4) Validation - During this phase it is ensured that the developed system 
unctions as originally intended. That is, it is validated that the system 
actually performs what it is supposed to do. 

The first phase of the life-cycle has already been performed. The 
research done by Demurjian and Hsiao [Ref. 1] has described the motivation, 
goals, and structure of the MLDS. The research conducted by Wortherly 
¡Ref. 3] has extended this work to describe in detail the purpose of the 
CODASYL-DML interface. Hence, the requirements specification is derived 


from the above research. 
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We have developed the design of the system using the above 
specification. A Systems Specification Language (SSL) [Ref. 12] is used 
extensively during this phase. The SSL has permitted us to approach the design 
from a very high-level, abstract perspective by : 

(1) enhancing communications among the program team members, 

(2) reducing dependence on any one individual, and 

(3) producing complete and accurate documentation of the design. 
Furthermore, the SSL has allowed us to make an easy transition from the 
design phase to the coding phase. 

We have used the C programming language [Ref. 13] to translate the 
design into executable code. Initially, we were not conversant in the language. 
However, our background in Pascal and the simple syntax of C have made it 
easy for us to learn. The greatest advantage of using C is the programming 
environment that it resides (i.e., the UNIX operating system). This 
environment has permitted us to partition the CODASYL-DML interface and 
then manage these parts in an effective and efficient manner. Perhaps, the 
only disadvantage with using C is the poor error diagnostics, having made 
debugging difficult. There is an on-line debugger available for use with C in 
UNIX for debugging. We have avoided this option and instead used 
conditional compilation and diagnostic print statements to aid in the 
debugging process. To validate our system we have used a traditional 
testing technique, i.e., path testing [Ref. 14]. We have tested those cases 
considered "normal". It is noteworthy to mention that testing, as we have 
done it, does not prove the system correct, but can only indicate the absence 
of problems with the cases that have been tested. 

3. Characteristics of the Interface Software 

In order for the CODASYL-DML interface to be successful, we have 
realized that it must be well designed and well structured. Hence, we are 
cognizant of certain characteristics that the interface must possess. Specifically, 
it must be simple. In other words, it must be easy to read and comprehend. 
The C code we have written has this characteristic. For instance, we often 


write the code with extra lines to avoid shorthand notations available in C. 
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These extra lines have made the difference between comprehensible code and 
cryptic notations. 

The interface software also must be understandable. This must be 
true to the extent that a maintenance programmer, for example, can easily grasp 
the functionality of the interface and the relation between it and the other 
pieces of the system. Our software possesses this characteristic and does not 
have any hidden side-effects that could pose problems months or years from now. 
Asa matter of fact, we have intentionally minimized the interaction between 
procedures to alleviate this problem. 

The interface must also be maintainable. This is important in light of 
the fact that almost 70% of all of the software life-cycle costs are incurred after 
the software becomes operational, i.e., in the maintenance phase. There are 
software engineering techniques we employed that have given the CODASYL- 
DML interface this characteristic. For example, we require programmers to 
document changes to the interface code when the changes are made. Hence, 
Maintenance programmers have current documentation at all times. The 
problem of trying to figure out the functionality of a program with dated 
documentation is alleviated. We also required the programmers to update their 
SSL specification as the code is being changed. Thus, the SSL specification 
consistently corresponds to the actual code. In addition, the data structures are 
designed to be general. Thus, it is an easy task to modify or rectify these 
structures to meet the demands of an evolving system. 

The research conducted by Demurjian and Hsiao [Ref. 1] provides a 
high-level specification of the MLDS. The thesis written by Wortherly [Ref. 3] 
extends the above work and provides a more detailed specification of a 
CODASYL-DML language interface. This thesis outlines the actual 
implementation of a CODASYL-DML interface. The appendices provide the 
SSL design for this implementation. 

A final characteristic that a CODASYL-DML interface should have is 
extensibility. A software product must be designed in a manner that permits 
the easy modification and addition of code. In this light, we have placed "stubs" 


in the correct locations of the KFS to permit the easy insertion of the code 
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needed to handle multiple horizontal screens of output. In addition, we have 
designed our data structures in such a manner that will permit subsequent 
programmers to easily extend them to handle not only multiple users, but also 


other language interfaces. 


C. A CRITIQUE OF THE DESIGN 

Our implementation of the CODASYL-DML interface possesses all of the 
elements of a successful software product. As noted previously, it is simple, 
understandable, maintainable, and extensible. Our constant employment of 
modern software engineering techniques have ensured its success. 

However, there are two techniques that are especially worthy of critique. 
The first of these is the use of SSL. Initially, we have felt that the 
implementation language may also serve as the language to specify program 
algorithms. However, in doing so, we have stifled our creativity. This is because 
we are concentrating not only on what the algorithm does, but also on what the 
constructs (data structures) of the algorithm are. The use of SSL has permitted 
us to concentrate on the functionality of the algorithm without a heavy 
concentration on its particular constructs. This has allowed us to view the 
algorithm in a detached manner so that the most efficient implementation 
for the constructs can be used. Although we initially felt that the 
development of the program with SSL may be too time-consuming, our opinions 
changed when we realized the advantages of SSL, and the overall complexity of 
the CODASYL-DML language interface itself. 

The way in which the data structures are designed is the other 
noteworthy software engineering technique. We have made extensive use of 
structures which are bound at compile time. We soon realize that in doing so, 
the computing resources (e.g., disk space) of the system are being depleted 
quite rapidly. Therefore, it is necessary for us to design the data structures in 
such a way that they can be managed in a dynamic fashion. Therefore, most of 
the data structures of the CODASYL-DML interface are linked lists. This 
design affords us the most convenient way to efficiently utilize the resources of 
the system. It is an easy task to use the C language’s malloc (memory 


allocate) function to dynamically create the elements of a list as we need them. 
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In addition, the free command is useful in releasing these same elements for 


subsequent use. 


D- THE DATA STRUCTURE 
The CODASYL-DML language interface has been developed as a single user 
system that at some point will be updated to a multi-user system. Two different 
concepts of the data are used in the language interface : (1) Data shared by all 
users, and (2) Data specific to each user. The reader must realize that the 
data structures used in our interface and described below have been 
deliberately made generic. Hence, these same structures support not only our 
CODASYL-DML interface, but the other language interfaces as well i.e., DL/I, 
SQL, and Daplex. 
1. Dita Shared by All Users 
The data structures that are shared by all users are the database 
schemas defined by the users thus far. In our case, these are network 
schemas, consisting of sets and attributes. These are not only shared by all 
users, but also shared by the four modules of the MLDS, i.e., LIL, KMS, KC, 
and KFS. Figure 4 depicts the first data structure used to maintain data. It is 
important to note that this structure is represented as a union. Hence, it is 
generic in the sense that a user can utilize this structure to support SQL, DL/I, 
CODASYL-DML, or Daplex needs. However, we concentrate only on the 
network(CODASYL) model. In this regard, the third field of this structure 
points to a record that contains information about a network(CODASYL) 


database. Figure 5 illustrates this record. The first field is just a character array 


union dbid node 
struct  rel_dbid node  *rel; 
struct  hie_dbid_node  *hie; 


struct net_dbid node “*net; 
struct ent_dbid_node *ent; 


Figure 4. The dbid node Data Structure. 


22 


struct net_dbid_node 


char NÓN vim a! name[DBNLength + 1); 
int Y ma num set; 

int | Á num rec; 

int Ab KHN dbkey; 

struct nset_ node *first set; 

struct nset node *curr set; 

struct nrec node *first rec; 

struct nrec node *curr rec; 

struct net dbid node “*next db; 


Figure 5. The net dbid node Data Structure. 


containing the name of the network database. The second and third fields 
contain an integer value representing the number of sets and the number of 
record types in the database. The fourth field also contains an integer value to 
give a different dbkey value to each record in the database. The fifth, sixth, 
seventh and ninth fields are pointers to other records containing information 
about each set and each record type in the database. Specifically, the fourth and 
sixth fields points to the first set and the first record type in the database while 
the fifth and seventh fields point to the current set and the current record type 
being accessed. The final field is just a pointer to the next network database. 

The data structure nrec_node contains information about each record 
type in the database (see Figure 6). This structure is organized in much the 
same fashion that the net dbid node is organized. The first field of the data 
structure holds the name of the record type. The next field contains the number 
of attributes in this particular record type. The third and fourth fields point to 
other record types which contain data on the first and current attribute of 
this record type. And finally, the last field is a pointer to the next record type 
in this database. 

The data structure nset node contains information about each set in the 
database (see Figure 7). The first field of the structure holds the name of the set. 


The second field contains the owner name of this set. The third field contains the 
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struct nrec node 


char name[RNLength + 1); 
int num attr; 
struct nattr node “first attr; 
struct nattr node ~~“ ¢urr attr: 
struct nrec node *next rec; 


Figure 6. The nrec node Data Structure. 


struct nset node 


char name|SNLength + 1); 

char owner name|ONLength + 1]; 
char member name[MNLength + 1); 
char insert mode[INLength + 1]; 
char i retent mode[RLength + 1]; 
struct set select node select mode; 

struct nrec node “owner; 

struct nrec node *mem ber; 

struct nset node *next set; 


Figure 7. The nset node Data Structure. 


member name of this set. The fourth and fifth fields serve as a flag to indicate 
the insertion and the retention mode. For instance, an insertion mode for a 
member record of a set can either be automatic or manual. Therefore,the 
characters "a", and "m" are used, respectively. The retention mode for a member 
record of a set can either be fixed, mandatory, or optional. Thus, the characters 
"f" "m", and "o" are used, respectively. The sixth field of this structure is a 
pointer to a data structure containing information about the set selection mode. 
The seventh field is a pointer to the owner record type of this set type. The 
eighth field is a pointer to the member record type of this set type. The final 


field is just a pointer to the next set type in the database. 
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The data structure set select node contains information about the set 
selection mode for each set in the database(See Figure 8). The first field serves 
as a flag to indicate the set selection mode. For instance, a set selection mode of 
a set type can either be by VALUE, by STRUCTURAL, by APPLICATION, or 
not specified. The characters "V", "S", "A", and "O" are used, respectively. If 
the set selection mode is by VALUE or by STRUCTURAL, the second field 
holds the item name of the specified record and the third field holds the name of 
the record. If the set selection mode is by STRUCTURAL, the fourth field holds 
the name of the second record , which is specified in the case of a by 
STRUCTURAL set selection criterion. 

Figure 9 shows the organization of the final data structure used to 
support the definition of the network database schema. This structure contains 
information about the attributes of each CODASYL record type. The first field is 
an array, holding, the name of the attribute. The second field holds the level 
number of this attribute, and the third field serves as a flag to indicate the 
attribute type. For instance, an attribute can either be an integer, a floating 
point number, or a string. The characters "i", "f", and "s" are used, 
respectively to represent these types. The fourth field indicates the maximum 
length that a value of this attribute type may possibly have. For example, if 
this field is set to ten, and the type of this attribute is a string, then the 
maximum number of characters that a value of this attribute type may have is 
ten. The fifth field indicates the maximum length of the decimal portion of this 
attribute, if the type of this attribute is floating point. The sixth field is also a 


struct set select node 


char select mode[SLength + 1); 
char item name[ANLength + 1); 
char record! name[RNLength + 1); 
char record2 name|RNLength + 1); 


Figure 8. The set select node Data Structure. 
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struct nattr node 


char name|ANLength + 1]; 
char level num[{ALLength + 1l; 
char type; 

int . length1; 

int length2; 

int dup flag; 

struct nattr node *next attr; 

struct nattr node *child; 

struct nattr node *parent; 


Figure 9. The nattr node Data Structure. 


flag used to indicate whether or not this particular attribute can have 
duplicates. The seventh field is a pointer to the next attribute in this record. If 
the level number of an attribute is bigger than the previous level number, then 
the eighth field is used to reference a data structure that contains information on 
the child of the current attribute. If the level number of an attribute is less than 
the previous level number, then the ninth field is used to reference a data 
structure that contains information on the parent of the attribute. The reader 


may refer to Appendices A through C to examine how these data structures are 
used in SSL. 
2. Data Specific to Each User 

This category of data represents information needed to support each 
user’s particular interface needs. The data structures used to accomplish 
this can be thought of as forming a hierarchy. At the root of this hierarchy is 
the data structure, user info, that maintains information on all of the current 
users of a particular language interface (see figure 10). The user info data 
structure holds the ID of the user, a union that describes a particular interface, 
and a pointer to the next user. The union field is of particular interest to us. 
As noted ear:ier, a union serves as a generic data structure. In this case, the 
union can hold the data for a user accessing either a CODASYL-DML language 
interface layer(LIL), a DL/I LIL, an SQL LIL, or a Daplex LIL. The li info 


union is shown in Figure 11. 
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struct user info 


char uid[UIDLength + 1); 
union li info li type; 
struct user info  *next user; 


Figure 10. The user info Data Structure. 


union li info 


struct sql info sql; 
struct dli info dli; 
struct dml info dml; 
struct dap info dap; 


Figure 11. The li info Data Structure. 


We are only interested in the data structures containing user 
information which relates to the CODASYL-DML language interface in this 
section. The structure used is referred to as dml info and is depicted in Figure 
12. The first field of this structure, curr db info, is itself a data structure and 
contains currency information on the database being accessed by a user. The 
second field, file, is also a data structure. The file data structure contains the file 
descriptor and file identifier of a file of CODASYL-DML transactions, 1.e., either 
queries or creates. The next field, dml tran, is also a data structure, and 
holds information that describes the CODASYL-DML transactions to be 
processed. This includes the number of requests to be processed, the first request 
to be processed, and the current request being processed. The fourth field of the 
dml info data structure, ddl files, is a pointer to a data structure which describes 
the descriptor and template files. These files contain information about the 
ABDL schema corresponding to the current network database being processed, 
1.€., the ABDL schema information for a newly defined network database. 

The next field of the structure, operation is a flag that indicates the 


operation to be performed. This can be either the loading of a new database 
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struct dml info 


struct curr db info) cura. 
struct file info file; 

struct tran info dm] tran; 
struct ddl info *ddl files; 
int operation; 
int answer; 
int error; 
union kms info kms data; 
union kfs info kfs data; 
union kc info ke data; 
struct cur table *cur table; 
int buff count; 


Figure 12. The dml info Data Structure. 


or the execution of a request against an existing database. The sixth field, 
answer, is used by the LIL to record the answer received through its interaction 
with the user of the interface. The remaining fields, kms data, kfs data, and 
ke data are unions that contain information required by the KMS, KFS, and KC. 
These are described in more detail in the next four chapters.The eleventh field 
points to records that implement the currency information “ible (CIT), as 
discussed by Meyer and MacDougal[Ref. 18 ]. The last field, buff count, is a 


counter variable used in KC to keep track of the result buffers. 


E. THE ORGANIZATION OF THE NEXT FOUR CHAPTERS 

The following four chapters are meant to provide the ao with a more 
detailed analysis of the modules constituting the MLDS. Each chapter begins 
with an overview of what each particular module does and how it relates to the 
other modules. The actual processes performed by each module are then 
discussed. This includes a description of the actual data structures used by the 


modules. Each chapter concludes with a discussion of module shortcomings. 
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IM. THE LANGUAGE INTERFACE LAYER (LIL) 


LIL is the first module in the CODASYL-DML mapping process, and is 
used to control the order in which the other modules are called. The LIL allows 
the user to input transactions from either a file or the terminal. A transaction 
may take the form of either a database description of a new database, or a 
CODASYL-DML request against an existing database. A transaction may 
contain multiple requests. This allows a group of requests that perform a single 
task, such as a looping construct in CODASYL-DML, to be executed together as 
a single transaction. The mapping process takes place when LIL sends a single 
transaction to KMS. After the transaction has been received by KMS, KC is 
called to process the transaction. Control always returns to LIL. where the user 
may close the session by exiting to the operating system. 

LIL is menu-driven. When the transactions are read from either a file or 
the terminal, they are stored in a data structure called net req info. If the 
transactions are schema definitions, they are sent to the KMS in sequential order. 
If the transactions are CODASYL-DML requests, the user is prompted by 
another menu to selectively choose an individual request to be processed. The 
menus provide an easy and efficient way for the user to view and select the 
methods of request processing desired. Each menu is tied to its predecessor, so 
that by exiting one menu the user is moved up the "menu tree". This allows the 


user to perform multiple tasks in one session. 


A. THE LIL DATA STRUCTURES 

LIL uses two data structures to store the user’s transactions and control 
which transaction is to be sent to the KMS. It is important to note that these 
data structures are shared by both LIL and KMS. 

The first data structure is named tran info and is shown in Figure 13. The 
first field of this record, first req, contains the address of the first transaction 
that has been read from a file or the terminal. The second field, curr req, 


contains the address of the transaction currently being processed. LIL sets this 
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struct tran info 


{ 


struct net_req info ‘*first_req; 
struct net req info ‘curr req; 
int no_ req; 


} 


Figure 13. The tran info Data Structure. 


pointer to the transaction that the KMS is to process next, and then calls the 
KMS. The third field, no_ req, contains the number of’ transactions currently in 
the transaction list. This number is used for loop control when printing the 
transaction list to the screen, or when searching the list for a transaction to be 
executed. 

The second data structure used by LIL is named net req info. Each copy 
of this data structure represents a user transaction, and thus, is an element of the 


transaction list. The net req info data structure is shown in Figure 14. 


The first field of this record, req, is a character string that contains the actual 
CODASYL-DML transaction. The second field, in_req, is a pointer to a list of 
character arrays that each contain a single line of one transaction. After all lines 
of a transaction have been read, the line list is concatenated to form the actual 
transaction, req. The third field of this record, req len, contains the length of the 


transaction. It is used to allocate the correct and minimal amount of memory 


struct net req info 


{ 


char “req; 
struct temp str info  *in reg; 
int req_len; 
struct net req info *sub_req; 
struct net req info “next req; 


Figure 14. The net req info Data Structure. 
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space for the transaction. If a transaction contains multiple requests, the fourth 
field, sub_req, points to the list of requests that make up the transaction. In this 
case, the field in req is the first request of the transaction. The last field, 


next req, is a pointer to the next transaction in the list of transactions. 


B. FUNCTIONS AND PROCEDURES 

LIL makes use of a number of functions and procedures in order to create 
the transaction list, pass elements of the list to the KMS, and maintain the 
database schemas. We do not describe each of these functions and procedures in 
detail. Rather, we provide a general description of the LIL processes. 

1. Initialization 

MLDS is designed to be able to accommodate multiple users, but is 

implemented to support only a single user. To facilitate the transition from a 
single-user system to a multiple-user system, each user possesses his own copy of 
a user data structure when entering the system. This user data structure stores 
all of the relevant data that the user may need during their session. All four 
modules of the language interface make use of this structure. The modules use 
many temporary storage variables, both to perform their individual tasks, and to 
maintain common data between modules. The transactions, in user data 
language form, and mapped kernel data language form, are also stored in each 
user data structure. It is easy to see that the user structure provides 
consolidated, centralized control for each user of the system. When a user logs 
onto the system, a user data structure is allocated and initialized. The user ID 
becomes the distinguishing feature to locate and identify different users. The 
user data structures for all users are stored in a linked-list. When new users 
enter the system, their user data structures are appended to the end of the list. 
In our current environment there is only a single element on the user list. Ina 
future environment, when there are multiple users, we simply expand the user list 
as described above. 

2. Creating the Transaction List 

There are two operations the user may perform. A user may define 

a new database or process CODASYL-DML requests against an existing 
database. The first menu that is displayed prompts the user to select the 
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operation desired. Each operation represents a separate procedure to handle 


specific circumstances. The menu looks like the following: 


Enter type of operation desired 
(1) - load a new database 
(p) - process old database 
(x) - return to the operating system 


ACTION C = 


For either choice (i.e., 1 or p), another menu is displayed to the user 
requesting the mode of input. This input may always come from a data file. If 
the operation selected from the previous menu had been "p", then the user may 
also input transactions interactively from the terminal. The generic menu looks 


like the following: 


Enter mode of input desired 
(f) - read in a group of transactions from a file 
(t) - read in transactions from the terminal 
(x) - return to the previous menu 


ACTION > 


Note that the "t" choice would be omitted if the operation selected from the 
previous menu had been to load a new database. Again, each mode of input 
selected corresponds to a different procedure to be performed. The transaction 
list is created by reading from the file or terminal, looking for an end-of- 
transaction marker or an end-of-file marker. These flags tell the system when one 
transaction has E and when the next transaction begins. When the list is 
being created, the pointers to access the list are initialized. These pointers, 
first req and curr req, have been described earlier in the data structure 
subsection. Both pointers are set to the first transaction read, in other words, the 
head of the transaction list. 
3. Accessing the Transaction List 

Since the transaction list stores both schema definitions and 
CODASYL-DML requests, two different access methods have to be employed to 
send the two types of transactions to KMS. We discuss the two methods 
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separately. In both cases, KMS accesses a single transaction from the transaction 
list. It does this by reading the transaction pointed to by the request pointer, 
curr req, of the tran info data structure (see Figure 13). Therefore, it is the job 
of the LIL to set this pointer to the appropriate transaction before calling KMS. 
a. Sending schema definitions to KMS 
When the user specifies the filename of a schema, (input 
from a file only) further user intervention is not required. To produce a new 
database, the transaction list of data definition statements is sent to KMS via a 
program loop. This loop traverses the transaction list, calling KMS for each data 
definition statement in the list. 
b. Sending CODASYL-DML Requests to KMS 
In this case, after the user has specified the mode of input, 
the user conducts an interactive session with the system. First, all CODASYL- 
DML requests are listed to the screen. As the requests are listed from the 
transaction list, a number is assigned to each transaction in ascending order, 
starting with the number one. The number appears on the screen to the left of 
the first line of each transaction. Note that each transaction may contain 
multiple requests. Next, an access menu is displayed which looks like the 


following: 


Pick the number or letter of the action desired 
(num) - execute one of the preceding transactions 
(d) - redisplay the list of transactions 
(x) - return to the previous menu 


ION => 


Since CODASYL-DML requests are independent items, the order in which they 
are processed does not matter. The user has the option of executing any number 
of CODASYL-DML requests. A loop causes the menu to be redisplayed after 
each CODASYL-DML request has been executed so that further choices may be 
made. 
4. Calling KC 

When KMS has completed its mapping process, the each 

transformed CODASTL-DML request have to be sent to KC to interface with the 
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kernel database system. Then, KC must update the currency information table 
(CIT) depending on the CODASYL-DML request. If, there are other 
CODASYL-DML requests on the same transaction, KMS continues its mapping 
process. Therefore, KC is immediately called, when its mapping process are 
completed for each CODASYL-DML request. 
5. Wrapping-up 

Before exiting the system, the user data structure described in 
Chapter IJ has to be deallocated. The memory occupied by the user data 
structure is freed and returned to the operating system. Since all of the user 


structures reside in a list, the exiting user’s node has to be removed from the list. 
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IV. THE KERNEL MAPPING SYSTEM (KMS) 


KMS is the second module in the CODASYL-DML mapping interface and is 
called from the language interface layer (LIL) when LIL receives CODASYL- 
DML requests from the user. The function of KMS is to: (1) parse the request to 
validate the user's CODASYL-DML syntax, and (2) translate, or map, the 
request to equivalent ABDL request(s). Once an appropriate ABDL request, or 
set of requests, has been formed, it is made available to the kernel controller 
(KC) which then prepares the request for execution by MBDS. KC is discussed 
in Chapter V. 


A. ANOVERVIEW OF THE MAPPING PROCESS 

From the description of KMS functions above we immediately see the 
requirement for a parser as a part of KMS. This parser validates the 
CODASYL-DML syntax of the input request. The parser grammar is the driving 
force behind the entire mapping system. _ 

1. The KMS Eee Translator 

KMS parser has been constructed by utilizing Yet-Another-Compiler 

Compiler (YACC) [Ref. 15]. YACC is a program generator designed for 
syntactic processing of token input streams. Given a specification of the input 
language structure (a set of grammar rules), the user's code to be invoked when 
such structures are recognized, and a low-level input routine, YACC generates a 
program that syntactically recognizes the input language and allows invocation of 
the user’s code throughout the recognition process. The class of specifications 
accepted is a very general one: LALR(1) grammars. It is important to note that 
the user’s code mentioned above is our mapping code that is going to perform the 
CODASYL/DML-to-ABDL translation. As the low-level input routine, we 
utilize a Lexical Analyzer Generator (LEX) [Ref. 16]. LEX is a program 
generator designed for lexical processing of character input streams. Given a 


regular-expression description of the input strings, LEX generates a program that 
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partitions the input stream into tokens and communicates these tokens to the 
parser. 

The parser produced by YACC consists of a finite-state automaton with 
a stack. It performs a top-down parse, with left-to-right scan and one token look- 
ahead. Control of the parser begins initially with the highest-level grammar rule. 
Control descends through the grammar hierarchy, calling lower and lower-level 
grammar rules which search for appropriate tokens in the input. As the 
appropriate tokens are recognized, some portions of the mapping code may be 
invoked directly. In other cases, these tokens are propagated back up the 
grammar hierarchy until a higher-level rule has been satisfied, at which time 
further translation is accomplished. When all of the necessary lower-level 
grammar rules have been satisfied and control has ascended to the highest-level 
rule, the parsing and translation processes are complete. In Section B, we give an 
illustrative example of these processes. 

2. The KMS Data Structures 

KMS utilizes, different kinds of structures for different kinds of requests. 
It, naturally, requires access to the CODASYL-DML input request structure 
discussed in Chapter II, the dm] tran structure. 

CIT has been described in Chapter 2. This structure carries all of the 
currency information for a particular run unit, and is vital to the proper 
translation and execution of CODASYL statements. LIL of the interface should 
initialize CIT. The KMS should have read access to CIT at all times, while any 
updates of the CIT should be done by KC only. 

The following data structures will be needed in KMS, and each is directly 





associated with a particular CODASYL statement. The first field of the 
net kms info structure, shown in Figure 15, is a pointer to the data structure 
that contains duplication information accumulated by the KMS during the 
grammar-driven parse. This data structure contains the name of an attribute that 
has DUPLICATES NOT ALLOWED specified in the schema definition, and a 
pointer to the next attribute with the same specification (see Figure 16). We use 


this list when setting the non duplicate flags in the attribute nodes. 
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struct net_kms info 


{ 


struct ndup_ node *ndup list; 
struct move list *move list; 
struct — select list *select_list; 
struct connect list  *connect list; 
struct abdl req *abdl; 

struct erase abdl “erase; 
struct find_abdl *find; 

struct - store abdl "store; 

struct get_node *get; 

struct - find _abdl *cur find; 


} 


Figure 15. The net kms info Data Structure. 


struct ndup node 


{ 


char i name[A NLength + 1); 
struct ndup node *next; 


} 


Figure 16. The ndup node Data Structure. 


The second field of the net_kms info structure is a pointer to the head of 
the move list structure (see Figure 17). The move list simulates the MOVE 
statements used as assignment statements by the host language COBOL in other 
CODASYL implementations. In our implementation, we create the move list 
structure to keep track of these assignment statements, and to validate the 
execution of other CODASYL-DML statements. The first field and second field 
of the structure point to the record template structure (see Figure 17). This 
structure keeps track of the name of the record type in the move statements. The 
third field of the move list points to the data item structure (see Figure 17). 
Each data item contains the attribute name, attribute type, and value 
information corresponding to the item that is the object of the MOVE statement. 
It should be noted that the value field in the data item record is a pointer to a 
variable-length character string. Although attribute names have a constant 


maximum-length constraint, the length of attribute values in the database is 
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limited only by the constraint placed on them by the user Mi the original 
database definition, and as such, they may be of varying lengths. 

The third field of the net kms info structure is a pointer to the 
select list data structure (see Figure 18). This data structure contains attribute 
names to be used to retrieve records from the database. The fourth field of the 
net kms info structure is a pointer to the connect list data structure (see Figure 


19). This data structure contains set type names to be connected or disconnected. 


struct move list 


{ 


struct record template “first rec; 
struct record template *cur rec; 
struct data item *cur item; 


} 


struct record template 


{ 


char name|RNLength + 1); 
struct record template  *next record; 
struct data item “item list; 


} 


Struct data item 


{ 


char name|ANLength + 1); 
char *value; 

char type; 

struct data item *next item; 


) 


Figure 17. The Move list Data Structures. 


struct select list 


{ 


char *item name; 
struct select list *next_item; 


} 


Figure 18. The select list Data Structure. 
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struct connect list 


{ 


char set type[SNLength + 1); 
struct connect list  *next set type; 


} 


Figure 19. The connect list Data Structure. 


The fifth field of the net_kms info structure is a pointer to the abdl req 
data structure (see Figure 20). The first field of this structure is a pointer to the 
actual ABDL request generated by the KMS, for DISCONNECT, CONNECT 
and MODIFY CODASYL-DML requests. The second field, operation, defines the 
type of request to be executed. The last field is a pointer to other records of the 
Same type. 

The sixth field of the net_kms info structure is a pointer to the 
erase abdl data structure (see Figure 22). This structure contains information 
about the ERASE CODASYL-DML request. The fist field of this data structure 
defines the type of request to be executed (i.e., ERASE ALL or ERASE specific 
record type). The second and third fields are pointers to the actual ABDL 
request generated by the KMS. The fourth field is a pointer to the 
member erase data structure. We use this field when the CODASYL-DML 
request is ERASE ALL. If the given record type is an owner of a non empty set, 


then we delete all of the members of the set owned by this record type (see 


struct abdl req 


{ 


char “abdl; 
int operation; 
struct abdl req  *next abdl; 


} 


Figure 20. The abdl req Data Structure. 
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Figure 21). The last field, result file, is used in KC to accumulate results 
obtained from MBDS when executing the ABDL requests. 

The seventh field of the net kms info structure is a pointer to the 
find abdl data structure (see Figure 23). The first field of this data structure, 
set type, contains the set name of the translated request. The second field, 
rec type, contains the record name of the translated request. The third field, 
abdl, is a pointer to the actual ABDL request generated by KMS. The fourth 
field, num_attr, contains the number of attributes in this particular record type 
of the translated request. The fifth field, operation, defines the type of FIND 
request to be executed (i.e, FIND ANY, etc.). The sixth field, dont update, 
indicates that there is no need to update the CIT table for the request being 


struct member erase 


{ 


char l set name|SNlength + 1]; 
char Papal: 
char * delete; 
char *template; 
struct net file info *result file; 
struct member erase  *eraseall, 
tnext 


Figure 21. The member erase Data Structure. 


struct erase abdl 


{ 


int operation; 
char *abdl; 
char *retrieve: 
struct member erase *member; 
struct net file info *result file; 


j 


Figure 22. The erase abdl Data Structure. 
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struct symbolic info 
char 
struct 


} 


struct suppres list 
char 
struct 


} 


struct set list 
char 
char 
char 
struct 


} 


struct 

{ 
char 
char 
char 
int 
int 
int 
struct 
struct 
struct 
struct 
struct 


} 


symbolic info 


suppres list 


set list. 


find_abdl 


set list 
suppres list 
symbolic info 
find abdl 


net file info 


name{ANLength + 1); 
*next; 


set type[SNLength + 1]; 
*next; 


set name[SNLength + me 
owner name[RNLength + 1), 
*dbkey; 


* next; 


set type[SNLength + 1): 
rec type[RNLength + 1); 
*abdl; 

num attr; 

operation; 

dont update; 

“set list; 

*Suppres; 

eelist: 

“next; 

“result file; 


Figure 23. The find abdl Data Structures. 
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processed. The seventh field, set list, is a pointer to the set list data structure. 
This structure is a list of set names. We use this field, when we update CIT 
table. The eighth field, suppres, is used by the KC to update the CIT table. The 


ninth field, tgt list is a pointer to the symbolic info data structure. This 


structure is a list of E names (the target list). The last field, result file is 
used in KC to accumulate results obtained from MBDS when executing the 
ABDL requests. 

The eighth field of the net kms info structure is a pointer to the 
store abdl data structure (see Figure 24). This structure contains information 
about the STORE CODASYL-DML request. The first field, rec_name, contains 
the record name of the translated request. The second field, ret_abdl is a pointer 
to a RETRIEVE request. This request is generated by the KMS in order to 
determine the existence of duplicate values for data items declared to have 
DUPLICATES NOT ALLOWED in the database schema. The third field, 
ins abdl, is a pointer to the INSERT request which will actually cause the record 
to be placed into the database. The fourth field, templatel, is used as working 


struct ret2 node 


{ 


char - set name[SNLength + 1]; 
char owner[RNLength + 1]; 

char select mode[SLength + 1); 
char insert _mode[INLength + 1); 
char * abdl; 

int flag; 

struct net file info  *result file; 

struct ret2 node REI. 


} 


struct store abdl 


{ 


char rec name[RNLength + 1); 
char "ret abdi; 

char *ins_abdl; 

char “templatel; 

int dont_update; 

struct ret2 node *ret2 abdl; 

struct suppres list *Suppres; 

struct net file info  *result file: 


i 


Figure 24. The store abdl Data Structures. 
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space by the KC. The fifth field, dont update, indicates that there is no need to 
update the CIT table for the request being processed. The sixth field, ret2 _abdl, 


is a pointer to a RETRIEVE request which returns the owner database rer Brice 
of the proper set occurrence for the new record (see Figure 24). The first field of 
the ret2 node structure, set name, contains the set name of the record to be 
inserted. The second field, owner, contains the name of the set type of the record 
to be inserted. The third field, select mode defines the set selection criteria for 
the record being stored. The fourth field, insert mode defines the set insertion 
mode for the record being stored. The fifth field, abdl, is a pointer to a 
RETRIEVE request which returns the owner database key value of all the set 
occurrences to which this new record belongs. The sixth field, flag, is used in KC 
to build fhe INSERT request. If we do not insert the new record into a set type. 
Then, we set this flag. The seventh field, result file, is used in the KC to 
accumulate results obtained from MBDS when executing the ABDL requests. 
The seventh field of the store abd] data structure, suppres, is used by KC to 
update the CIT table. The last field, result file, is used in KC to accumulate 
results obtained from MBDS when executing the ABDL requests. 

The ninth field of the net_kms info structure is a pointer to the get node 
data structure (see Figure 25). This structure contains information about the 
GET CODASYL-DML request. The first field, type, contains the record name in 
question. The second field, operation, identifies the type of GET format being 


used (i.e., GET record type or GET item list IN record type). The third field, 


struct get node 


{ 


char type[RNLength + 1]; 
int operation; 

struct select list *tgt list; 

struct get_ node *next; 


} 


Figure 25. The get_node Data Structure. 


43 


tgt list, is a pointer to the select list data structure. It includes a list of items to 
be returned. If the format is GET record type, this field would be NULL, and 
KC would return all attributes of the record. The same is true for the simple 
GET format. The last field is a pointér to other records of the same type. Thus, 
these records are connected in a linearly linked list. 

The tenth field of the net_ kms info structure is a pointer to the last 
FIND request. We use this field to display correct result buffer when the user 
issue GET request. 


B. FACILITIES PROVIDED BY THE IMPLEMENTATION 

In this section, we discuss those CODASYL-DML facilities that are provided 
in our implementation of the network (CODASYL) interface. We do not discuss 
the CODASYL/DML-to-ABDL translation in detail. This subject is discussed by 
Wortherly [Ref. 3]. Rather, we provide an overview of the salient features of 
KMS, accompanied by one illustrative example of the parsing and translation 
process. User-issued requests may take two forms, schema definition statements, 
or CODASYL-DML database manipulations. Appendix B contains the design of 
our implementation, written in a system specification language (SSL). 

l. Database Definitions 

When the user informs the LIL that the user wishes to create a new 

database, the job of KMS is to build a schema that corresponds to the schema 
definition statements input by the user. The LIL initially allocates a new 
database identification node (net dbid node a Figure 5) with the name of 
the new database, as input by the user. The LIL then sends the KMS a complete 


schema definition, which has the form : 


SCHEMA NAME IS database name ; 
RECORD NAME IS record type; 
DUPLICATES ARE NOT ALLOWED FOR attr_name ; 
Ol attr 1; CHARACTER length . 
attr 2; FIXED length . 


RECORD NAME IS record type ; 
DUPLICATES ARE NOT ALLOWED FOR attr_name, attr_name ; 
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attr 1; CHARACTER length . 


SET NAME IS set type ; 
OWNER IS record type ; 
MEMBER IS record type ; 
INSERTION IS insertion mode 
RETENTION IS retention mode ; 
set selection mode ; 


SET NAME IS set type; 





The sequence of statements in the schema definition is significant. First, 
all record declarations have to appear, followed by all declarations for each record 
statement, an additional record node (nrec node shown in Figure 6) is added to 
the database schema under construction. For each subsequent attribute 
statement, an additional attribute node (nattr node shown in Figure 9) is added 
to the schema for the current record under construction. Then, for each set 
statement, an additional set node (nset_node shown in Figure 7) is added to the 


database schema under construction. The database _  identificatio node 


(net_dbid_node shown in Figure 5) holds the number of records and the number 
of sets in the schema, the database name, and the initial value of dbkey. Each 
record node holds the number of Dies in that record, and the record name. 
Each attribute node holds the attribute name, level number, length, type, and 
non duplicate flag value. Each set node holds the set name, the owner’s name, 
and the member’s name, the insertion mode, the set selection mode, and the 
retention mode. 

When KMS has parsed all of the statements included in the schema 
_definition, the result is a completed database schema, as shown in Figure 26. Not 
shown in Figure 26 is the list of attribute nodes that is connected to each record 
node. The network (CODASYL) database schema, when completed, serves two 
purposes. First, when creating a new database, it facilitates the construction of 
the MBDS template and descriptor files. Secondly, when processing requests 
against an existing database, it allows validitiy checks of the records, sets, and 


attribute names used. It also serves as a source of information for type checking. 
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+--------—---- -+ +---—----—---- + 


| record type | | record type | 
a = + x 
a + = 
| set type | | set type | 
A + => 
po + 
| record type | 
A + 


Figure 26. The Network Database Schema. 


2. Database Manipulations 
When the user wishes the LIL to process requests against an existing 
database, the task of KMS is to map the users CODASYL-DML request to 
equivalent ABDL requests. 
a. The Mapping Processes: An Example 
In this subsection we present an illustrative example of the KMS 
mapping process (i.e., parsing and translation) for a simple CODASYL-DML 
FIND ANY call. We begin by showing the grammar for the dml portion of 
KMS. We then step through the grammar and demonstrate appropriate portions 
of our design in the system specification language (SSL). We only show those 
portions of the design that are relevant to the example, i.e., those that would 
actually be executed. The entire KMS design is shown in Appendix C. 
The relevant grammar is shown in Figure 27. The source CODASYL-DML call 


to be utilized for our example is the following: 


MOVE Cleveland TO CITY IN SA 
FIND ANY SA USING CITY IN SA 
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(Note: The MOVE statement is an assignment statement found in the host 
COBOL language.) The ABDL request generated in response to such a 
CODASYL-DML call is as follows: 


[RETRIEVE ((TEMPLATE = SA) and (CITY = Cleveland)) 
(SNO, SNAME, STATUS, CITY, DBKEY) BY DBKEY | 


To begin our discussion, let us first synchronize the reader. At the 
beginning of the mapping process, the parse descends the grammar hierarchy 
searching for appropriate tokens in the input that may satisfy one of the 
grammar rules. Therefore, the parser descends through the ddl statement rules 
(schema definition statements). After finding no matching tokens for these rules, 
the parser eventually descends to the dml rule (data manipulation language). 

When the dm! rule is first called, it immediately calls the 
dml statement rule, then starts to search for appropriate tokens in the input that 
satisfy one of its sub rules. In our example, the move rule is called. For the sake 
of brevity in the example, we will not go through the mapping process for the 
MOVE statement. We need only be aware that the new value for the attribute 
CITY in the record template for record type SA, has been set to the value 
Cleveland, by the previous parse/translation. Now, we may proceed with the 
mapping of the FIND ANY statement. 

When the find rule is called, the FIND token is recognized satisfying 
the first portion of the rule. Control now goes to the record selection expr rule. 
This rule then searches for tokens in the input that satisfy one of its sub rules. In 
our example, the ANY record type portion of this rule is satisfied. The 
record type rule recognizes the token, SA, via the terminal, IDENTIFIER. At 
this point, we need to perform some translation. The following SSL is invoked 


before the remaining portion of the rule is satisfied. 
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statement: ddl statement 


| dml 


dml: dml statement 
| dml dml statement 


dml statement: set flag 
| move 
| get 
| find 
| store 
| connect 
| disconnect 
| erase 
| modify 
| perform loop 
| if then 


find: FIND record selection expr curr suppression 


record selection expr: ANY record type USING item list 
IN record type 


curr suppression: LSQUARE supp expr RSQUARE 
| empty 


item list: item name 
| item list COMMA item name 


record type: IDENTIFIER 
item name: IDENTIFIER 


Figure 27. The KMS dml statement Grammar. 


record selection expr: ANY record type 
{ 
if (record type’ record template node is 
not on move list) 

perform error(1) 
return 

else 
alloc and init new ‘find’ node 
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find type = ANY in find node 

copy record type to find node 

alloc and init new abdl str 

alloc and init new tgt_ list 

/* begin forming a RETRIEVE request */ 

copy "| RETRIEVE (( TEMPLATE = "record type')" 
to abdl str 

end if 

select list = NULL 


USING item list IN record type 
| CURRENT record type WITHIN set_type 


We first check to see if the record type is on the move list. If it is not. the 
system gives an error message and exits the parser. If it is on the move list, we 
allocate and initialize a new find node. At the same time, we initialize an abd] 
string to be used for forming the ABDL request. The target list is also allocated 
and initialized at this point. Next, we copy "[RETRIEVE ((TEMPLATE = 
‘record type’ )" to the abdl str. Then, we free the select list. The select list 
holds the attribute names from the item list rule. 

The next token encountered is the USING token. It matches USING 
in the FIND ANY rule. So, the item list rule below is called. This rule 
recognizes the token, CITY, in the CODASYL-DML call and creates the 
select list. 


item list: item _name 


{ 


put the first item name on select list 


| item list COMMA item name 


{ 


put successive item names on select list 


} 


The IN token is recognized next and satisfied. Control is then passed 
to the record type rule. This rule recognizes the token, SA, and the parsing 
process is complete. We must now perform more translation in order to complete 


the record selection expr rule as indicated below. 
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record selection expr: ANY record type 
{ 
} 
USING item list IN record type 
{ 
if (record type’ is same as previous 
‘record type’) 
if (any data item on select list is not 
defined for ’record type’) 
perform error(2) 
return 
end if 
else 
create tgt list item for all attributes 
of ‘record type’ record 
for (each data item on select list) 
if (data item’ not on move list ) 
perform error(1) 


return 
end if 
else 
get ‘item value’ from move list 
concat "and (’data_ item’ = item value’)" 
to abdl str 
end else 
end for 
concat ")('tgt list’)" to abdl str 
checkmember () | 


concat "DBKEY) BY DBKEY]" to abdl str 
connect abdl str to find node 
end else 

end if 

else 

perform error(6) 

return 

end else 


| CURRENT record type WITHIN set_type 


First, we check to see if the last record type is the same as the 
previous record type. If it is not, the system gives an error message and exits the 


parser. If it is correct, we must check the select list for any attribute names that 
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are not defined for the record type. If undefined names are on the select list, the 
system gives an error message and exits the parser. If there are no undefined 
names we must create a tgt list for all of the attributes of the record type. Then. 
we must check each attribute name on the select list for inclusion on the 
move list, because we need the value of the attribute in order to issue the 
RETRIEVE request. If the attribute is not on the move list, the system gives an 
error message and exit the parser. If the attribute is on the move list, we must 
concatenate each attribute name on the select list, and it’s value from the 
move list to the abdl str. Next, we concatenate ")(’tgt list’) " to the abdl str. 
(Note: We created the tgt list earlier, thus, we simply concatenate that list to 
the abdl str.) Next, we check to determine if the record in question is a member 
of any set. If the record does belong to one or more sets, we concatenate the 
MEMset type attribute for those sets to the target list of the abdl str being 
processed. We use the MEMset type values to update the CIT table properly. 
Next, we concatenate "DBKEY ) BY DBKEY]" to the abdl str. 

Now, the record selection expr rule is completed, and contro] returns 
to the curr suppression rule. The empty portion of the curr suppression rule is 
matched, satisfying the curr suppression rule. Now, the dml statement and dml 
rules are fully satisfied, and control returns to the start statement. The parsing 


and translation process for our example is now completed and the find node is 





passed to the KC for execution. 
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V. THE KERNEL CONTROLLER 


The Kernel Controller (KC) is the third module in the MLDS CODASYL 
language interface. It is called by the language interface layer (LIL) when a new 
database is being loaded, and is called by the kernel mapping system (KMS) 
when an existing database is being manipulated. KC is the module which 
performs the task of controlling the submission of ABDL transactions to the 
multi-backend database system (MBDS) for processing. 

KC must perform the following functions: (1) submit transactions to the 
MBDS, (2) receive and store results of transactions, (3) update the currency 
information table, and (4) cause the proper data to be returned to the user. 

The procedures that make up the interface to the KDS (i.e., MBDS) are 
contained in the test interface (TI) of: MBDS. To fully integrate the KC with the 
KDS, the KC calls procedures which are defined in the TI. Due to upcoming 
hardware changes in MBDS, we decided not to test the KC on-line with the TI. 
Our solution to this problem has been to design the system exactly as if it were 
interfacing with the TI. However, for each call to a TI procedure, we have 
created a software stub that performs the same functions as the actual TI 
procedure. The reader should realize that all interactions with the TI procedures 
described in the KC are actually made with these software stubs, rather than 
with the on-line TI procedures. 

In this chapter we discuss the processes performed by the KC. This 
discussion is in two parts. First, we examine the data structures relevant to the 
KC, followed by an examination of the functions and procedures found in the 
KC. Appendix C contains the design of our KC implementation, written in a 


system specification language (SSL). 


A. THE KC DATA STRUCTURES 
In this section, we review some of the data structures discussed in Chapter II, 
focusing on those structures that are accessed and used by KC. One data 


structure used by KC is the dml info record shown in Figure 28. KC makes use 
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of only four fields in this record. The first field, operation, defines what action is 
going to be taken by KC. 

The second field, buff count, is an integer used to maintain control of the file 
buffers associated with the results of each RETRIEVE request. 

The third field, kms data, is a pointer to the kms info union data structure. 
This structure points to the net kms info data structure, which allows us to 
execute proper ABDL request(s). 

The fourth field, cur table, is a pointer to the cur table data structure (see 
Figure 29), which contains currency information for the database in use. The 
first field of the cur table data structure points to the run unit data structure. 
This data structure contains information about the current of run unit. The term 
"run_unit" means the most recently accessed record of any type whatsoever. The 
first field of the run_unit data structure, holds the name of the current record of 
the run unit. The second field, dbkey, holds the database key value of the 
current record of the run_unit. We do not use any information relating to the 


current record of the record type in our KMS implementation. Thus, we do not 


struct dml _info 


{ 


struct curr db info  curr db; 
struct. file info file; 

struct tran_info dml tran; 
struct ddl info *ddl files; 
int operation; 
int answer; 
int error; 

int buff count; 
union ‘kms info kms data; 
union kfs info kfs data; 
union kc_ info kc data; 
struct cur table *cur table; 


i 


Figure 28. The dml info Data Structure. 
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struct run_unit 


{ 


char rec type[RNLength + 1); 
int dbkey; 


} 


struct cur set 


{ 


char set name[SNLength + 1); 
char type[RNLength + 1); 

int dbkey; 

char member/RNLength + 1]; 
char owner|RNLength + 1): 
int owner dbkey; 

struct cur set *next set; 


} 


struct cur table 


{ 


struct run unit Tom 
struct cur set *set type: 
struct cur set *cur_ set; 


} 


Figure 29. The cur table Data Structure. 


include the current of record type in our implementation of the currency 
information table. The second and third fields of the cur table data structure, 
point to the cur set data structure. This data structure contains information 
about the current of set type. The first field of this data structure contains the 
name of the set type. Note that sometimes the current of set type is going to be 
an owner, and sometimes it is going to be a member. The second field of the 
cur set data structure contains this information. The third field, dbkey. holds the 
database key value of the current of set type. The fourth and fifth fields hold the 
name of the member and owner record types of the set type. The sixth field. 
owner dbkey, holds the database key value of the owner record of the set type. 
We create the cur set data structures dynamically. If the set type being 


processed is not on the currency table, then we create a new cur set data 
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structure to hold information about this set type. The last field of the cur set 
data structure is a pointer to other data structures of the same type that connect 
the data structures in a linearly linked list. 

The net file info is used by KC to store information about the file buffers 
containing the results obtained for each RETRIEVE request (see Figure 30). 
The first field, buff, contains the file name and file id. This information is 
required so that the appropriate files may be written to and read from, as 
necessary. The second field, count, is simply an integer representing the number 
of results in the file buffer. The next field, buff loc, indicates the KC’s location in 
the file buffer. For instance, after the first value is pulled from a file buffer, this 
field indicates that the KC’s position is now at the beginning of the second result. 
The fourth field, status, serves as a flag so that a file buffer is opened under the 
correct status. The fifth field, max chars, defines the maximum length of 
response in the result buffer. The sixth field is a pointer to a character string 
that holds the last result value pulled from the file buffer. This value may be 
used in the building of subsequent requests, or it may be used to update the CIT 


struct file info 


{ 


char fname[FNLength + 1); 
FILE *fid; 


} 


struct net _file info 


{ 


struct file info buff; 

int count; 

int buff loc; 

int status; 

int max chars; 
char *curr_ buff val; 
char “tem str; 


I 


Figure 30. The net_file info Data Structure. 
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table. The last field is a pointer to a character string that holds the response 


record. This field is used by KFS to display the result to the user. 


B. FUNCTIONS AND PROCEDURES 
The KC makes use of a number of different functions and procedures to 
manage the transmission of the translated CODASYL-DML requests (i.e., ABDL 
requests) to the KDS. Not all of these functions and procedures are discussed in 
detail. Instead, we provide the reader with an overview of how the KC controls 
the submission of the ABDL requests to MBDS. 
1. The Kernel Controller 
The kernel controller procedure is called by LIL when a new database is 
being loaded, and is called by KMS when an existing database is being 
manipulated. This procedure provides the master control over all other 
procedures used in KC. This procedure is a case statement that calls different 
procedures based upon the type of ABDL transactions being processed. If a new 
database is being created, the load tables procedure is called. If the transaction 
is of any other type, then the appropriate procedure for processing that 
transaction is called. If the transaction is none of the above, there is an error, and 
an error message is generated with control returned to LIL. 
2. Creating a New Database 
The creation of a new database is the least difficult transaction that the 
KC handles. The load tables procedure is called, which performs two functions. 
First, the test interface (TI) dbl template procedure is called. This procedure is 
used to load the database-template file created by the KMS. Next, the TI 
dbl dir tbls procedure is called. This procedure loads the database-descriptor 
file. These two files represent the attribute-based metadata that is loaded into 
the KDS, 1.e., MBDS. After execution of these two procedures, control returns to 
the LIL. 
3. The FIND Requests 
The find requests handler procedure is called by the Kernel Controller 
procedure to handle FIND requests. The find requests handler procedure is a 
large case statement. The find requests handler procedure takes action 


depending on the FIND request being processed. If the FIND request is either 
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the FIND ANY, FIND FIRST, FIND LAST, FIND WITHIN or FIND OWNER, 
find requests handler takes the same action. It executes the RETRIEVE request 
associated with the statement, and calls the Find update procedure. If the FIND 
request is either a FIND NEXT, FIND PRIOR or FIND DUPLICATE, the 
find requests handler procedure must first find the correct find abdl data 
structure and determine the correct buffer location in the result file of this data 
structure. The procedure then calls the Find update procedure. If the FIND 
request is a FIND CURRENT, then find requests handler simply calls the 
Find update procedure. 

The Find update procedure is called by the find requests handler, if the 
user does not use SUPPRESS UPDATE mode. The main goal of this procedure is 
to set up currency information depending on the type of find request. 

The following examples illustrate the logic used in this procedure. 


Suppose the following CODASYL-DML request is issued by the user: 


MOVE S555 TO SNO IN SP 
FIND ANY SP USING SNO IN SP 


KMS translates this request into the following ABDL RETRIEVE request: 


| RETRIEVE (( TEMPLATE = SP ) and ( SNO = SS5 )) 
(SNO, PNO, QTY, MEMSSP, MEMPSP, DBKEY) BY DBKEY | 


The Kernel Controller procedure is then called by KMS to execute this request 
and update the CIT table. The Kernel Controller procedure thhen calls the 
find requests handler procedure. This procedure provides the master control over 
all FIND requests. In our example, case AnyFin statement is satisfiyied. Since 
the RETRIEVE request is complete, it may be immediately forwarded to KDS 
for execution. This is accomplished by calling dml execute. This procedure uses 
two TI procedures and the dml check requests left procedure. In general, 
dm] execute sends the ABDL request to KDS and waits for the last response to 
be returned. Results for a given request are placed in a unique file buffer 
associated with each request data structure. The file results procedure controls 


this process. 
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After the last response is returned, the Find update procedure takes 
control. The action taken is dependent upon the particular case satisfied in the 
procedure. In our example, case AnyFin statement is satisfied. The SP 
record type is a member of both SSP and PSP set types. If the user does not 
specify any currency suppression, we update the currency of all set types to 
which this record type belongs, and the currency of the run_unit. If the set types 
are not on the CIT table, we create new cur set data structures to hold the 
necessary information, if the user specifies set types for currency suppression, we 
only update the currency of these particular set types and the currency of the 
run_unit. If the user specifies SUPPRESS UPDATE, then we do not update the 
CIT table. 

Finally, control returns to KMS via the Kernel Controller procedure and 
the find requests handler procedure. If there is another request in the same 
transaction, KMS continues the mapping process. If not, control returns to LIL, 
and we can pick another transaction, or return to any of the other MENUs in 
LIL. 

4. The Modify, Connect, and Disconnect Requests 

If the request is Modify, Connect, or Disconnect, the request handler 
procedure is called by the Kernel Controller procedure. The first thing done by 
the request handler procedure is to execute all ABDL UPDATE requests created 
by KMS. If the request is Connect or Disconnect, the request handler procedure 
takes appropriate action to update the CIT table. We use the connect list data 
structure (see Figure 19) to update set type(s) correctly. 

5. The Move Request 

There is no action taken by the Kernel Controller procedure for the 
Move Request. We mentioned before in KMS, the Move request is just an 
assignment statement. 

6. The Store Request 

If the request is the Store Request, the store requests handler procedure 
is called by the Kernel Controller. The following examples illustrate the logic 
used in this procedure to control the processing of this type of request. Suppose 


the following CODASYL-DML requests are issued by the user: 
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MOVE SS$4 TO PNO IN PA 
MOVE PP2 TO SNO IN SA 
MOVE PP1 TO SNO IN SP 
MOVE SS3 TO PNO IN SP 
MOVE 100 TO QTY IN SP 
STORE SP 


KMS translates these CODASYL-DML requests into the following three ABDL 
RETRIEVE requests and one ABDL INSERT request: 


Í RETRIEVE ((( TEMPLATE = SP ) and (SNO = PP1 )) or 
(( TEMPLATE = SP ) and ( PNO = SS3))) 
( DBKEY ) BY DBKEY ] 


| RETRIEVE ((TEMPLATE = SA) and (SNO = PP2))(DBKEY) | 
| RETRIEVE ((TEMPLATE = PA) and (PNO = SS4))(DBKEY) | 


| INSERT (<TEMPLATE,SP>,<DBKEY,***>, 
<SNO,PP1>,<PNO,SS3>,<QTY,100>, 
<MEMSSP,***>,<MEMPSP,***>) ] 


The first task performed by the store requests handler procedure is to execute 
the first RETRIEVE request attached to the store abdl data structure. This 
request determines if there are records in the database which have attribute 
values that are not to be duplicate. The execution of this RETRIEVE is 
accomplished by calling dml execute. If the request buffer created for this 
RETRIEVE is non empty at the end of execution, there is an error. If the 
request buffer is empty, then we continue the execution in the following manner. 
To insert the new record into the correct set occurrences, we need to 
know the database keys of the owners of the set occurrences. For this reason, we 
issue the next two RETRIEVE request(s) above. These requests are created by 
KMS depending on the set selection criteria and the set insertion mode of the 
new record. These RETRIEVE requests are executed by the dml execute 
procedure, and the results are placed in a unique file buffer associated with each 


request data structure. Then, the build request is called to complete the INSERT 
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request. The database keys of the owners of the set occurrences are pulled from 
the appropriate result buffer(s) and substituted for the place holding asteriks to 
complete the INSERT request. In our implementation, the order of the 
RETRIEVE requests, and the order of the attributes, MEMset type are the 
same. Thus, we can easily complete the INSERT request. After this operation, 
the INSERT request is issued by calling dml execute. Now, if no currency 
suppression list is attached to the store abdl data structure, the CIT table is 
updated to reflect a change in the SSP and PSP currency, as well as, the current 
of run unit. Finally, control returns to KMS via the Kernel Controller 
procedure. 
7. The Erase Request 

The ERASE request is handled by the erase requests handler. This 
procedure first checks the type of the erase request (i.e.,, ERASE ALL 
record type or ERASE record type ). If the type of the erase request is ERASE 
record type, then this procedure ‘proceeds in the following manner. The 
RETRIEVE request attached to the erase abd] data structure is executed by 
calling dml execute. This request determines, whether or not the record being 
deleted is an owner of a non empty set. If the request buffer is empty, then all 
that remains is to issue the DELETE request attached to the erase abdl data 
structure. This request deletes the current record of the run unit. After the 
deletion, erase requests handler update the CIT table by setting the current of 
run unit indicator to NULL. If the result buffer of the first RETRIEVE request 
is not empty, the system gives an error message and the erase request fails. 

If the type of the erase request is ERASE ALL record type. We have a 
different sequence of events. ERASE ALL deletes the current of run_unit whether 
or not it is the owner in a non empty set. Indeed, if it is the owner in a 
non empty set, this option really comes into its own. All the members connected 
to the set are also erased. If any of these members happens to be connnected to 
some other set of another type, this does not matter. Furthermore, if any of these 
members happens to be themselves an owner in a non empty set, then their 
members in turn are erased. To deal with this problem, the 


erase requests handler procedure calls the erase member procedure recursively. 
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We first issue the RETRIEVE request to get the database key values of the 
members of the set. Then, we complete the DELETE request attached to the 
ret2 node data structure, and issue each DELETE request to KDS via the 
dml execute procedure. After this process, the erase requests handler executes 
the DELETE request attached to the erase abd] data structure to delete the 
current of the run unit. Once again, the CIT table is updated to reflect any 
changes in currency i.e., current of set types become NULL as appropriate, as 
well as, the current of run unit. 
8. The Get Request 

The GET request is handled by the dml kfs procedure. This procedure 
uses the result buffer of the last FIND request issued. It simply looks at the 
operation field of the get node data structure, and retrieves either the entire 
record or specific fields of the record from the result buffer, and displays these 
results to the user. We will examine this process more closely in the next chapter 


(The Kernel Formatting System). 
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VI. THE KERNEL FORMATTING SYSTEM (KFS) 


KFS is the fourth module in the CODASYL-DML language interface, and 
is called by the Kernel Controller (KC) when it is necessary to display results to 
the user. The transformation of data into the appropriate format is a very simple 
task for the CODASYL-DML language interface. Unlike most other language 
interfaces, no change in format is required. The form that the data is in when it 
is retrieved from MBDS is the same form in which it is to be displayed to the 
user. The task of KFS is reduced to simply printing out the results obtained 
from the ABDL equivalents of the CODASYL-DML requests. But, there is one 
exception, we do not display the database key values to the user in the result 
buffer. In this chapter, we discuss how KC stores the data that the KFS 
eventually displays, and how the KFS outputs this data. 


À. THE KFS DATA STRUCTURE 

KFS utilizes just one of the data structures defined in the language 
interface. The kfs net info record, shown in Figure 31, contains information 
needed by KFS to process the results. The first field in this record, response, 
contains the result from MBDS which is loaded by KC just prior to calling the 
KFS. The second field, curr pos, lets KFS know where it is in the response 
buffer. This assists KFS in maintaining the correct orientation in the response 
buffer. The last field, res len, indicates the length of the response buffer. This 


value is used as a halting condition. 


struct kfs _net info 


{ 


char *response; 
int Curr pos; 
int res len; 


} 


Figure 31. The kfs net info Data Structure. 
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B. THE FILING OF CODASYL-DML RESULTS 

KC stores the results obtained from a CODASYL-DML request by calling 
the file results procedure. This procedure first opens the result file for writing in 
the response. The procedure reads in the name of the first attribute and stores it 
in a variable, in addition to storing it in the results file. The attribute value is 
then stored in the results file. A while loop then handles the storing of the 
remaining attribute-value pairs into the results file. Before an attribute name is 
stored into the results file, a check is made to determine if this attribute matches 
the attribute name of the first attribute in the result. If the attribute names 
match, we have completed storage of one result and are ready to store the next 
result. An end-of-line marker is inserted in the results file at this point before the 
next attribute-value pair is stored. Otherwise, the attribute-value pair is stored 
without the end-of-line marker. This check is one of the reasons that the KFS 


task of formatting output is so easy for the CODASYL-DML language interface. 


~ 


e THE KFS PROCESS 

The KFS module is contained in the small procedure, dml kfs. KFS is 
only called by KC when the results of a request are to be displayed to the user. 
The get request causes this action to be taken. The only task that the KFS 
performs is to display to the screen the attribute-value pair found on the current 
line in the result buffer of the last FIND request. A loop prints out this line, a 
character at a time, depending of the type of the get request (i1.e., GET or GET 
item list IN record type ). This means KFS retrieves either the entire record or 


specific fields of the record from the result buffer. 
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VII. CONCLUSION 


In this thesis, we have presented the implementation of a CODASYL- 
DML language interface. This is one of four language interfaces that the multi- 
lingual database system supports. In other words, the multi-lingual database 
system is able to execute transactions written in four well-known and important 
data languages, namely, DL/I, SQL, CODASYL-DML, and Daplex. In our case, 
CODASYL-DML transactions are executed by way of LIL, KMS, KC and KFS. 
The work accomplished in this thesis is part of an ongoing research effort being 
conducted at the Laboratory for Database Systems Research, Naval Postgraduate 
School, Monterey, California. 

The need to provide an alternative to the development of separate stand- 
alone database systems for specific-data models and languages has been the 
motivation for this research. In this regard, we have shown how a software 
CODASYL-DML language interface may be constructed without the need of a 
stand-alone CODASYL database management system. We have extended the 
work of Wortherly [Ref. 3] by implementing the algorithms he presents for the 
CODASYL-DML language interface. Additionally, we have provided a general 
organizational description of the MLDS. 

A major design goal has been to design a CODASYL-DML language 
interface to MBDS without requiring changes to be made to MBDS or ABDL. 
We have achieved this goal. All CODASYL-DML transactions are performed in 
the CODASYL-DML interface. MBDS continues to receive and _ process 
transactions written in the unaltered syntax of ABDL. Additionally, our 
implementation does not require any changes to the syntax of CODASYL-DML. 

Two facilities suggested by Wortherly [Ref. 3] that are not included in our 
implementation are the looping facility, PERFORM-LOOP, and the IF-THEN 
statement. These are not included, due to the lack of time to implement them. 
Therefore, we chose to concentrate our implementation on the native 


CODASYL-DML statements first. If more time will become available, we can 
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implement the these facilities, since there is not logical difficulty in implementing 
them. Our level-by-level top down approach to designing the interface has been 
a fine choice as well. This approach permits follow-on programmers to easily 
maintain and modify the code. | 

Once all four interfaces have been completely implemented, MLDS should 
be tested as a complete system for the projected efficiency, effectiveness, and 
responsiveness to user needs. It is anticipated that this research and 
development effort will ultimately result in a new era for database management 


that will allow for increased productivity in database management. 
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APPENDIX A - THE LIL PROGRAM SPECIFICATIONS 


module CODASYL/DML-INTERFACE 


db-list : list; /* list of existing relational schemas a 
head-db-list-ptr: ptr; /* ptr to head of the relational schema list */ 
current-ptr: ptr; /* ptr to the current db schema in the list */ 
follow-ptr: ptr; /* ptr to the previous db schema in the list */ 
db-id : string; /* string that identifies current db in use */ 


proc LANGUAGE-INTERFACE-LAYER(); 
/* This proc allows the user to interface with the system. */ 
/* Input and output: user CODASYL-DML requests q 


stop : int; /* boolean flag */ 
answer: char; /* user answers to terminal prompts */ 


perform DML-INIT(); 

stop = false’; 

while (not stop) do 

/* allow user choice of several processing operations */ 
print ("Enter type of operation desired"); 
print (" (l) - load new database"); 
print (" (p) - process existing database"); 
print (" (x) - return to the to operating system"); 
read (answer); 
case (answer) of 
I’: /* user desires to load a new database */ 
perform LOAD-NEW(); 

p’: /* user desires to process an existing database */ 
perform INITIALIZE CUR TABLE(); 
perform PROCESS-OLD(); 

x’: /* user desires to exit to the operating system */ 
/* database list must be saved back toa file */ 
store-free-db-list (head-db-list, db-list); 
stop = true’; 
exit(); 
default: /* user did not select a valid choice from the menu */ 

print ("Error - invalid operation selected"); 
print ("Please pick again")’ 
end-case; 
/* return to main menu */ 
end-while; 
end-proc; 
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proc DML-INIT(); 


end-proc; 


proc LOAD-NEW(); 

This proc accomplishes the following: dl 

/* (1) determines if the new database name already exists, ay 
(2) adds a new header node to the list of schemas, $ 

/* (3) determines the user input mode (file/terminal), ry 

(4) reads the user input and forwards it to the parser, and  */ 

(5) calls the routine that builds the template/descriptor files */ 

answer: int; /* user answer to terminal prompts */ 

more-input: int; /* boolean flag */ 

proceed: int; /* boolean flag */ 

stop : int; /* boolean flag */ 

db-list-ptr: ptr; /* pointer to the current database */ 

req-str: str; /* single create in DML form */ 

ptr-abdl-list: ptr; /* ptr to a list of ABDL queries (nil for this proc)*/ 

tfid, dfid: ptr; /* pointers to the template and descriptor files */ 


/* prompt user for name of new database */ 
print ("Enter name of database"); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 
stop = ‘false’; 
while (not stop) do 
/* determine if new database name already exists */ 
/* by traversing list of network db schemas */ 
if (db-list-ptr.db-id = existing db) then 
print ("Error - db name. already exists"); 
print ("Please reenter db name"); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 


end-if; 
else 
if (db-list-ptr + 1 = ’nil’) then 
stop = ‘true’; 
else 


/* increment to next database */ 
db-list-ptr = db-list-ptr + 1; 
end-else; 
end-while; 
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/* continue - user input a valid ’new’ database name */ 

/* add new header node to the list of schemas and fill-in db name */ 
/* append new header node to db-list */ 

create-new-db(db-id); 


/* the KMS takes the DML defines and builds a new list of relations */ 
/* for the new database. After all of the defines have been processed */ 
/* the template and descriptor files are constructed by traversing  */ 
/* the new database definition (schema). E 


more-input = ‘true’; 
while (more-input) do 
/* determine user’s mode of input */ 
print ("Enter mode of input desired"); 
print (" (f) - read in a group of defines from a file"); 
print (" (x) - return to the main menu"); 
read (answer); 


case (answer) of 
P: /* user input is from a file */ 
perform READ-TRANSACTION-FILE(); 
perform DBD-TO-KMS(); 
perform FREE-REQUESTS(); 
perform BUILD-DDL-FILES(); 
perform KERNEL-CONTROLLER(); 


xX: i" exit back to LIL ”/ 


more-input = false’; 


default: /* user did not select a valid choice from the menu */ 
print ("Error - invalid input mode selected"); 
print ("Please pick again"); 
end-case; 
end-while; 


end proc; 
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proc PROCESS-OLD(); 
/* This proc accomplishes the following: 
/* (1) determines if the database name already exists, */ 
/* (2) determines the user input mode (file/terminal), */ 
/* (3) reads the user input and forwards it to the parser */ 


* 


answer: int; /* user answer to terminal prompts */ 

found: int; /* boolean flag to determine if db name is found */ 
more-input: int;  /* boolean flag to return user to LIL */ 

proceed: int; /* boolean flag to return user to mode menu */ 
db-list-ptr: ptr; /* pointer to the current database */ 

req-str: str; /* single query in DML form */ 


ptr-abdl-list: ptr; /* pointer to a list of queries in ABDL form */ 
tfid, dfid: ptr; /* pointers to the template and descriptor files */ 


/* prompt user for name of existing database */ 
print ("Enter name of database"); 

readstr (db-id); 

db-list-ptr = head-db-list-ptr; 


found = ’false’; 
while (not found) do 
/* determine if database name does exist */ 
/* by traversing list of network schemas */ 
if (db-id = existing db) then 
found = ‘true’; 
end-if; 
else 
db-list-ptr = db-list-ptr + 1; 
/* error condition causes end of list(’nil’) to be reached */ 
if (db-list-ptr = ’nil’) then 
print ("Error - db name does not exist"); 
print ("Please reenter valid db name"); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 
end-if; 


end-else; 


end-while; 
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/* continue - user input a valid existing database name */ 
/* determine user's mode of input */ 


more-input = ’true’; 
while (more-input) do 
print ("Enter mode of input desired"); 
print (" (f) - read in a group of DML requests from a file"); 
print (" (t) - read in a single DML request from the terminal"); 
print (" (x) - return to the previous menu"); 
read (answer); 
case (answer) of 
P: /* user input is from a file */ 
perform READ-TRANSACTION-FILE(); 
perform DMLREQS-TO-KMS(); 
perform FREE-REQUESTS(); 


Y: /* user input is from the terminal */ 
perform READ-TERMINAL(); 
perform DMLREQS-TO-KMS(); 
perform FREE-REQUESTS(); 


x’: /* user wishes to return to LIL menu */ 
more-input = ‘false’; 


default: /* user did not select a valid choice from the menu */ 
print ("Error - invalid input mode selected"); 
print ("Please pick again"); 
end-case; 


end-while; 


end-proc; 


proc READ-TRANSACTION-FILE(); 
/* This routine opens a dbd/request file and reads the transactions */ 


/* into the transaction list. If open file fails, loop until valid */ 
/* file entered g 


while (not open file) do 
print ("Filename does not exist"); 
print ("Please reenter a valid filename"); 
readstr ( file); 

end-while; 
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proc READ-FILE(); 
/* This routine reads transactions from either a file or the */ 
/* terminal into the user's request list structure so that * 


/* each request may be sent to the KERNEL-MAPPING-SYSTEM. */ 


end-proc; 


proc READ-TERMINAL(); 
/* This routine substitutes the STDIN filename for the read */ 
/* command so that input may be intercepted from the terminal */ 


end-proc; 
proc INITIALIZE-CUR-TABLE(); 
/* This proc initialize the CIT table before starting  */ 
/* to execute CODASYL-DML request(s). Se 
end-proc; 
proc DBD-TO-KMS(); 
/* This routine sends the request list of database descriptions */ 
/* one by one to the KERNAL-MAPPING-SYSTEM a 
while (more-dbds) do 
KERNAL-MAPPING-SYSTEM(); 


end-while; 


end-proc; 
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proc DMLREQS-TO-KMS(); 
/* This routine causes the DML requests to be listed to the screen. */ 
/* The selection menu is then displayed allowing any of the a 
/* DML requests to be executed. ai 


perform LIST-DMLREQS(); 
proceed = ‘true’; 
while (proceed) do 
print ("Pick the number or letter of the action desired"); 


print ("| (num) - execute one of the preceding DML requests"); 
print (" (d) - redisplay the file of DML requests"); 
print (" (x) - return to the previous menu" ); 


read (answer); 


case (answer) of 
‘num’ : /* execute one of the requests */ 
traverse query list to correct query; 


perform KERNAL-MAPPING-SYSTEM(); 


'd? : /* redisplay requests */  _ 
perform LIST-DMLREQS(); 


x’? : /* exit to mode menu */ 
proceed = ‘false’; 


default : /* user did not select a valid choice from the menu */ 
print (" Error - invalid option selected"); 
print (" Please pick again"); 
end-case; 


end-while; 


end-proc; 
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APPENDIX B- THE KMS PROGRAM SPECIFICATIONS 
x 
ia Currency Indicator Table 
/* References made in the following specification to CIT refer 
/* to the Currency Indicator Table. This table consists of struc- 
/* tures that hold information identifying the current record of 
/* record type, set type, and run_ unit (run_unit is the applica- 
* tion program being run). The following is the proposed struc- 
/* ture for this table [Ref. 13]. 


struct CIT 
a { 


struct RUN UNIT 
struct rec type node 
struct set type node 


srun; 
*next_rec_type; 
“next set type; 


m } 
: struct RUN UNIT 


char rec typel |; 
int dbkey; 


a } 


For each record type in schema: 
struct rec type node 
ia ( 
char type| |; 
int dbkey; 
struct rec type node *next rec type; 


} 


For each set type in schema: 
struct set type node 


a boolean OWNER; 
i char TYPE| |; 
i int dbkey; 

a, char member| |; 
i char owner| |; 
he int owner dbkey; 


struct set type node *next set type; 


boolean: first move = TRUE /* flag for MOVE operation */ 
boolean: first time /* general purpose flag */ 
boolean: sys flag value /* boolean value of system flags */ 
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ptr: curr temp rec /* ptr to last record added to move list */ 

ptr: curr temp item /* ptr to next item node to be added to 
record template node of movelist */ 

list: suppression list /* list of record types and/or set types */ 
for which currency updates are suppressed */ 


list: select list /* list of data items used for record section */ 
list: connect list /* list of sets to which current of run 

unit is to be connected or disconnected */ 
list: tgt list /* list of attribute names to be accessed */ 
list: move list /* list of record templates used with 


MOVE statement */ 
list: curr non dup list /* list of data items for which duplicates 
are not allowed in current record type */ 
int: level number /* level of data item in record types */ 
char: member type /* string variable to hold a name */ 
7} 
start statement 


statement: dd] statement 
| dml 
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dml: dml statement 
| dml dml statement 
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dd] statement: schema defn record list set list 


) 


schema defn: SCHEMA NAME IS schema name SEMI COLON 

{ 
locate db id schema header node 
if (db names do not match) 

print ("Error-given db name doesn’t 

match name in file") 

perform yyerror() 

return 
end if 
initialize db key /* starting value is 1 */ 


} 


) 
record list: record _ desc 


set db id node ndn first rec ptr 


} 
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| record list record desc 


connect successive record nodes 


} 


) 


record desc: record data item list 


{ 


curr non dup list = NULL 


} 


record: RECORD NAME IS 


allocate and init a new 
record node (NREC NODE) 
allocate curr non dup list 
db id node ndn num rec++ 
} 
record spec 


record spec: record type 


if (record type not defined yet) 
copy record type to current 
record node (NREC_ NODE) 
make this the current record node 
end if 
else 
print ("Error-’record type’ record 
doubly defined") 
perform yyerror() 
return 
end else 


SEMI COLON duplicates list 


) 
set_list: empty 
| set_desc 
set db id node ndn first set ptr 


} 


| set list set_ desc 
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{ 


connect successive set node(s) 


} 


set desc: set desig owner spec member spec 


set desig: SET NAME IS 


{ 

allocate and init a new set node (NSET_ NODE) 

db id node ndn num set++ 

} 

set type 

{ 

if (set type not yet defined) 
copy set type to current set node (nsn_ name) 
establish curr set ptr 

end if 

else 
print ("Error-'set type” set doubly defined in db") 
perform yyerror() 

end else 


SEMI COLON 
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owner spec: OWNER IS aa SEMI COLON 


aa: record type 


if (record type not defined) 
print ("Error-’record type’ record does not exist") 
perform yyerror() 
return 

end if 

else 
copy record type to current set node (nsn_owner name) 
locate record type node 
nsn_ owner(ptr) = record type node 

end else 


| SYSTEM 


J 
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member spec: MEMBER IS record_type 


if (record type not defined) 
print ("Error-’record type’ record does not exist") 
perform yyerror() 
return 

end if 

else 
copy record type to current set node (nsn member name) 
locate record type node 
nsn member(ptr) = record_type node 

end else 


SEMI COLON insert clause retention clause 
alloc set_select node 


set_select_clause SEMI COLON 
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duplicates list: empty 
| dupl SEMI COLON 


) 


dup!: duplicate spec 
| dup] duplicate spec 


3 


duplicate spec: DUPLICATES ARE NOT ALLOWED FOR item _ spec 


3 


item spec: item name 


{ 


alloc new non_dup node 
copy item name to non dup node 
add non dup node to curr non dup list 


| item spec COMMA item name 
alloc successive non dup nodes 


copy successive item names to non dup nodes 
add successive non dup nodes to curr non_ dup list 


} 
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data item list: item desc 


connect new attr-node to record node 


} 


| data item list item desc 


connect successive attr node(s) to record node 


} 


item desc: level num 


allocate and init a new attr node (NATTR NODE) 
NATTR NODE nan level num = level_number 
record node nrn num attr++ 


} 


data item desc 

{ 

if (nan level num = level number of current attribute node) 
connect new attr node to current attr node 
if (nan_level number > 1) 

connect nan parent ptr of new node 

end if 

end if 

else if (nan level number > level number of current attr node) 
connect nan child ptr of current attr node to new attr node 
connect nan parent ptr of new attr node to current attr node 

end else if 

else 
locate last attr node with same level number 
set that node’s nan next attr ptr to the new attr node 
update current attr pointer 

end else 


data item desc: item name 


{ 


copy item name to attr node (NATTR NODE) 
if (item_name not on curr_non dup list) 


attr node nan dup flag = 1 
end if 


SEMI COLON data type PERIOD 


3 
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level num: empty 


{ 


level number 


1 /* default value */ 
| INTEGER 


level number = INTEGER 
} 


data type: CHARACTER INTEGER 


{ 
attr node nan lengthl = INTEGER 


attr node nan length2 = 0 
attr node nan type = ’c’ 


| FIXED INTEGER 


attr node nan lengthl = INTEGER 
attr node nan length2 = 0 
attr node nan type = ‘1’ 


} 
| FIXED INTEGER 


{ 
attr node nan lengthl = INTEGER 


} 
INTEGER 


{ 
attr node nan length2 = INTEGER 


attr node nan type = f 


} 


insert clause: INSERTION IS AUTOMATIC 
{ 


set node nsn insert = ’a’ 


} 
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| INSERTION IS MANUAL 
{ 


set node nsn insert = 


} 
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retention clause: RETENTION IS FIXED 
set node nsn retent = f 
} 
| RETENTION IS MANDATORY 


set node nsn retent = ’m’ 


} 
| RETENTION IS OPTIONAL 
{ 


set node nsn retent = ’o 


} 


set select clause: empty 


{ 


set node nsn select = ’o 


j 
| SEMI COLON SET SELECTION IS BY set select _spec 


) 


set select spec: VALUE OF item_name IN record type 

{ 

if(valid attr(item name,record type)) 
copy 'v” to set_select node select mode 
copy item name to set select node item name 
copy record type to set select node recordl 
copy BLANK to set select node record2 

end if 

else 
print("Error-’item_ name’ not valid for ‘record type’) 
perform yyerror() 
return 

end else 


| STRUCTURAL item name IN record type 
if(valid_attr(item_name,record_type)) 
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copy ’s’ to set select node select_mode 
copy item_name to set select node item_name 
copy record type to set_select node record] 
end if 
else 
print("Error-'item name” not valid for "record _type”") 
perform yyerror() 
return 


} 


EQ item name IN record type 


if(previous item name equals this item_name) 
if(valid _attr(item_n name,record type)) 
copy record type to set select node record2 
end if 
else 
print("Error-’item name’ is not valid for ’record type™") 
perform yyerror() 
return 
end if 
else 
print("Error-’item_ name’ items do not match") 
perform yyerror() 
return 
end else 


APPLICATION 
{ 


copy ‘a’ to set select node select_mode 
copy BLANK to recordl, record2, item name 


} 


? 


dml statement: set flag 
| move 


| get 
connect 
disconnect 
modify 


perform loop 
if then 
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set flag: MOVE f value TO f name 


3 


f value: YES 


sys flag value = TRUE 


} 
| NO 


sys flag value = FALSE 


f name: EOF 
eof = sys flag value 


} 
| NOTFOUND 
{ 


notfound = sys flag value 


} 


9 


/* The MOVE statement is a COBOL assignment statement that assigns a */ 
/* value to a particular data field in a record template. We usea */ 
/* list structure for this purpose. el 


move: MOVE item value 


if (first_ move = TRUE) 
alloc and init move list 
first move = FALSE 
end if 
create new data item node 
copy ‘item value’ to value field in data item node 
establish curr temp item pointer 


} 


TO item name 


{ 


copy ‘item name’ to name field in data item node 
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IN record type 
{ 
if (item name not in record type for current schema) 
perform error(2) 
return 
end if 
else if (record type’ node on move list) 
connect curr temp item to record _template node 
end else if 
else 
create new record template node 
copy ‘record type’ to name field of record template node 
connect curr temp item to record _ template node 
add record template node to move list 
update curr temp rec pointer 
end else 


) 


/* The GET statement takes the entire current record of the run unit */ 
/* or specified data fields of the current record of the run unit  */ 
/* and returns the values to the user. */ 


get: GET 
{ 
alloc and init new ‘get’ node 
select list = NULL /* reset select list */ 


} 


mmn 


? 


mm: item list IN record type 


if (record type’ is not equal to CIT.RUN UNIT.type) 
perform error(3) 
return 
end if 
else 
get type = ITEMS in get node 
copy record type to get node 
for (each data_item on item list) 
if (data_item’ is not defined for record type) 
perform error(2) 
return 
end if 
else /* create pseudo tgt list */ 
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copy data item to get node 
end else 
end for 
end else 


| record type 


if ("record type” is not equal to CIT.RUN UNIT.type) 
perform error(3) 
return 
end if 
else 
get type = RETURN ALL in get node 
copy ‘record type’ to get node 
end else 


} 


| empty 


get type = RETURN ALL in get node 
copy CIT.RUN UNIT.type to get node 
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/* The FIND statements establish the current of run unit, record type, */ 
/* and set type. ai 


find: FIND record selection expr curr suppression 


/* The FIND ANY means: find any record of type record type whose */ 
/* values for item1 through itemn match those in that record’s */ 
/* template in the user work area. | 


record selection expr: ANY record type 
{ 
if (record type’ record template node is not 
on move list) 

perform error(1) 
return 

else 
alloc and init new ’find’ node 
find type = ANY in find node 
copy record type to find node 
alloc and init new abd! str 
alloc and init new tgt_ list 
/* begin forming a RETRIEVE request */ 
copy "[ RETRIEVE ((TEMPLATE = ’record type’)" 
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to abdl str 
end if 
select list = NULL 
} 


USING item list IN record type 


if (‘record type’ is same as previous record type’) 
if (any data item on select_list is not 
defined for record type) 
perform error(2) 
return 
end if 
else . 
create tgt list item for all attributes 
of ‘record type’ record 
for (each data item on select list) 
if (data item’ not on move list) 
perform error(1) 
return 
end if 
else 
get ‘item value’ from move list 
concat "and (‘data item’ = ’item_value’)" 
to abd] str 
end else 
end for 
concat ")('tgt list”) by DBKEY]" to abdl str 
connect abdl str to find node 
end else 
end if 
else 
perform error(6) 
return 
end else 


/* The FIND CURRENT means: Make the current of set_type the current */ 
/* record of the run unit. r 


| CURRENT record type WITHIN set_type 


if (CIT.set_type.TYPE is not equal to ’record type’) 
perform error(7) 
return 
end if 
else 
/* current of run_unit becomes current of ’set type’ */ 
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alloc and init new ’find’ node 

find type = CURRENT in find node 

copy record type to find node 

copy set_ type to find node 

copy CIT.set type.dbkey to find node 
end else 


} 


/* The FIND DUPLICATE means: Find the first record in the current set */ 
/* type occurrence whose value for item] through itemn matches those */ 

/* for the same items in the current set type occurrence, not the UWA */ 

/* record template. This implementation assumes the records being re- */ 

/* quested are already in a buffer. =i) 


| DUPLICATE WITHIN set_type 


alloc and init new ‘find’ node 

find type = DUPLICATE in find node 
copy set_type to find node 

select list = NULL /* reset select list */ 


USING item list IN record type 


if ((record type is not CIT.set type.TYPE) or 
(record type is not CIT.set_type.member)) 
perform error(8) 
return 
end if 
else 
copy record type to find node 
for (each data item on select list) 
if (any data item on select list is not 
defined for record type) 
perform error(2) 
return 
end if 
else /* create a pseudo tgt list */ 
copy data item to find node 
end else 
end for 
end else 
} 
/* This statement means: Find the FIRST, LAST, NEXT, or PRIOR record_*/ 
/* type record within the current set type occurrence. The ll token */ 
/* takes the value FIRST, LAST, NEXT, or PRIOR. * 
| ll record type WITHIN set_type 


86 


{ 


if ("record type” is not a valid member type 
for "set type”) 
perform error(5) 
return 
end if 
else 
copy record type to find node 
copy set type to find node 


/* RETRIEVE all member records of set occurrence */ 


alloc and init new abdl str 
alloc and init new tgt list 


copy "(RETRIEVE ( 
(TEMPLATE = CIT.set type.member) and 
(MEMBER.set type = CIT.set type.owner _dbkey))" 
to abd] str 

create tgt list for all attributes of member record 

concat "(’tgt list’) by DBKEY]" to abdl str 

connect abd] str to find node 

end else 


} 


/* The FIND OWNER means: Find the owner of the current set_type occurrence */ 
| OWNER WITHIN set_type 


alloc and init find’ node 

find type = OWNER in find node 
copy set type to find node 

alloc and init new abd] str 

alloc and init new tgt_list 


/* form RETRIEVE request */ 


copy "(RETRIEVE ((TEMPLATE = CIT:set_type.owner) 
and (DBKEY = CIT.set_type.owner dbkey))" 
to abdl str 
create tgt list for all attributes of owner record 
concat "(’tgt_list’)|" to abdl str 
connect abd] str to find node 
} 
/* This statement means: Find the first record type record within the */ 
/* current set_type occurrence whose values for item1 through itemn */ 
/* match the values found in the record type template in the UWA, not */ 
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/* the values in the current of set_type asin the FIND DUPLICATE. */ 
| record type WITHIN set type CURRENT 


if ("record type’ not a member type of ’set_type’) 
perform error(5) 
return 

end if 

else 
alloc and init new ’find’ node 
find type = WITHIN in find node 
copy record type to find node 
copy set type to find node 
alloc and init new abd str 
alloc and init new tgt_list 


/* begin forming RETRIEVE request */ 


copy "[RETRIEVE ((TEMPLATE = "record type”) and 
(MEMBER.set type = ClT.set type.owner dbkey)" 


to abdl str 
create tgt list for all attributes of ’record_ type’ 
record 
select list = NULL /* reset select list */ 
end else 


USING item list IN record type 
{ 
if (any data item on select list is not defined 
for ‘record type’) 
perform error(2) 
return 
end if 
else if (any data item on select list 
not on move list) 
perform error(1) 
return 
end else if 
else 
for (each data item on select list) 
get ‘item value’ from move list 


concat "and (’data item’ = ’item value’) 
to abdl str 
end for 


concat ")(’tgt list?) by DBKEY]" to abdl str 


connect abdl _str to find node 
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end else 


} 


ll: FIRST 


alloc and init new ‘find’ node 
find type = FIRST in find node 


LAST 


alloc.and init new ‘find’ node 


find type = LAST in find node 


NEXT 


alloc and init new ‘find’ node 
find type = NEXT in find node 


PRIOR i 


alloc and init new ‘find’ node 


find type = PRIOR in find node 


curr suppression: LSQUARE supp expr RSQUARE 
| empty 
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supp expr: SUPPRESS UPDATE 
| UPDATE type_ spec 


type spec: set type 
add set type to suppression list 
| type spec COMMA set_type 


add successive set types to suppression list 


} 
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/* This statement means: Delete the current record of the run unit, */ 
/* and all of its descendents regardless of whether they are owners of */ 
/* other sets. g. 


erase: ERASE ALL record type 


if (record type’ is not CIT.RUN_UNIT.type) 
perform error(3) 
return 
end if 
else 
alloc and init new ’erase’ node 
erase type = ALL in erase node 
for (each set_type in schema) 
if (CIT.set type.owner dbkey = CIT.RUN UNIT.dbkey) 
member type = CIT.set_type.member 


/* form RETRIEVE to get member records */ 

alloc and init new abd] str 

copy"|RETRIEVE(MEMBER.set type = CIT.RUN_UNIT.dbkey) 
(DBKEY) by DBKEY]" to abdl str 


connect abd] str to erase node 


/* erase member records */ 

alloc and init new abdl str 

copy"|DELETE((TEMPLATE = ’member type’) and 
(DBKEY = ***))|" to abdl str 


connect abdl str to erase node 


/* delete all descendants of member records */ 
perform erase all(member type,erase node) 
end if 


end for 


/* delete current of RUN UNIT */ 
alloc and init new abd] str 
copy "[DELETE((TEMPLATE = "record type”) and 
(DBKEY = CIT.RUN UNIT.dbkey))|" to abdl str 
connect abdl str to erase node 
end_else 


} 
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/* This statement means: Delete the current record of the run unit if */ 
/* and only if, it is not the owner of a non-empty set. =f 


| ERASE record type 


{ 

if (record type’ is not CIT.RUN_UNIT.type) 
perform error(3) 
return 

end if 


else 


/* erase one record - current of RUN UNIT */ 
alloc and init new ’erase’ node 
erase type = NULL in erase node 


/* form RETRIEVE to see if ’record type’ is */ 
/* owner of non empty set a) 
alloc and init new abdl str 
copy "[RETREIVE(" to abdl str 
first time = TRUE f 
for (each set_type in schema) 
if (record type’ is owner type of set_type) 
if (first_time) 
concat "(MEMBER.set type = CIT.RUN UNIT.dbkey)" 
to abd] str 
first time = FALSE 
end if 
else 
concat "or (MEMBER.set type = CIT.RUN_UNIT.dbkey)" 
to abdl str 
end else 
end if 
end for 
concat ")(DBKEY) by DBKEY]" to abdl str 


connect abdl str to erase node 


/* for DELETE request */ 
alloc and init new abdl str 
copy "[DELETE ((TEMPLATE = CIT.RUN_UNIT.type) and 
(DBKEY = CIT.RUN UNIT.dbkey))|" to abdl str 
connect abdl str to erase node 
end else 


} 
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/* The STORE means: Create a new record in the database using values */ 

/* supplied by the user via MOVE statements, for the data items of */ 

/* the specified record type. The is connected to all sets in which */ 

/* INSERTION IS AUTOMATIC. The appropriate occurrence of the sets */ 
/* must be selected before the new record can be connected. This is */ 

/* done based on the SET SELECTION clause specified in the database */ 


/* schema definition for the sets in question. ai 
store: STORE record type 


if ("record ype’ record template node is not on move list) 
perform error(1) 
return 
end if 
alloc and init new ’store’ node 
alloc and init new abdl str 
copy "(RETRIEVE (" to abdl str 
first time = TRUE 
for (each data item in schema for ’record type’) 
if (nan_dup flag is set) i 
if (data item in move list ’record type’ record template) 
get data item value from move list 
if (first time = TRUE) 
concat"((TEMPLATE = "record type”) and 


(data item' = "item value'))" to abdl str 
first time = FALSE 
end if 
else 
concat "or ((TEMPLATE = ’record type’) and 
(data item’ = ’item value’))" to abdl str 
end else 
end if 
end if 
end for 


concat")(DBKEY) by DBKEY]" to abdl str 
connect retrieve request to store node 
alloc and init new abdl str 


/* Form an INSERT request */ 
copy"|INSERT (<TEMPLATE,’record type’>,<DBKEY,***>" to abdl str 
for (each ’data item’ in schema for ’record type’) 
if ("data item” not on move list for "record type”) 
perform error(4) 
return 
end if 


else 
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get data item value from move list 
concat",<’item_ name’,’item value’>" to abdl str 
end else 
end for 


/* Now determine which set occurrences the new record belongs to */ 
/* and add proper attribute-value pairs to the INSERT abdl str to */ 
/* indicate set membership. The following FOR loop and CASE state-*/ 
/* ment fill the INSERT abd] str with the proper pairs. j. 
for (each set_type in schema in which ’record type’ is a member) 
case (set selection mode) of 


/* set selection is by applicaton */ 
a: perform by application(INSERT abd] str) 


/* set selection is by value */ 
v: perform by value(INSERT abdl str) 


/* set selection is by structural */ 
s: perform by structural(INSERT abdl str) 


/* no set selection criteria was given */ 


o: perform by default(INSERT abd] str) 


end case 
end for 
concat "|" to INSERT abdl str 
connect INSERT abdl str to store node 
alloc and init suppression list 


} 


curr suppression 


connect suppression list to store node 


} 


3 


/* The MODIFY means: Modify the entire current record of the run unit */ 
/* or the specified data items in that record. The new values are */ 
/* supplied by the user via the UWA. T 


modify: MODIFY 
{ 


select_list = NULL /* reset select list */ 


} 
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item list IN record type 
{ 
if (record type’ is not current of run unit) 
perform error(3) 
- return 
end if 
if ("record type’ record template node is not on move list) 
perform error(1) 
return 
end if 
if (any data item on select list not defined for ‘record type’) 
perform error(2) 
return 
end if 
else 
alloc and init new ’modify’ node 
locate record template node on move list for ’record_ type’ 
for (each data item on select list) 
alloc and init new abd! str 
/* form UPDATE request */ 
copy "[ UPDATE ((TEMPLATE = ’record_type’) and 
(DBKEY = CIT.RUN UNIT. dbkey))" to abdl str 


get ‘item value’ from move list 


concat "(data item’ = ‘item value’)|" to abdl str 
connect abdl str to ’modify’ node 
end for 
end else 





record type 
{ 
select list = NULL /* reset select list */ 
if (record type” not current of run unit) 
perform error(3) 
return 
end if 
if (record type’ record template node is not on move list) 
perform error(1) 
return 
end if 
else 
alloc and init new ’modify’ node 
for (each data item in record type) 
if (data item not on move list for ’record type’) 
perform yyerror(4) 
return 


end if 
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else 
alloc and init new abdl str 


/* form an UPDATE request */ 
copy "| UPDATE ((TEMPLATE = ’record type’) and 
(DBKEY = CIT.RUN UNIT.dbkey)) to abdl str 


get new ‘item value’ from move list 


concat "(’data_ item’ = ’item_value’)|" to abdl str 
connect abdl str to ’modify’ node 
end else 
end for 
end else 


} 
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/* The CONNECT means: Connect the current record of the run unit to the */ 
/* current occurrence of the specified set type. There may be several */ 
/* sets listed in the statement. P 


connect: CONNECT record_type TO 


if (record type’ is not current of run unit) 
perform error(3) 
return 

end_if 

else 
alloc and init connect list 

end else 


} 


set_type list 


alloc and init ‘connect’ node 
for (each ’set_type’ on connect list) 
if ("record type’ is not a member type record for ’set_type’) 
or (INSERTION is not manual) 
perform error(5) 
return 
end if 
else 
alloc and init new abdl str 
copy "[UPDATE ((TEMPLATE = "record type”) and 
(DBKEY = CIT.RUN UNIT.dbkey)) 
(MEMBER .set_type = CIT.set type.owner dbkey)|]" 
to abdl str 
connect new abdl str to connect’ node 
end else 
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end for 
connect list = NULL  /* reset connect list */ 


} 


set type list: set type 
add ’set_ type’ to connect list 
| set type list COMMA set type 


add successive ’set_type’(s) to connect list 


} 
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/* The DISCONNECT means: Disconnect the current record of the run unit */ 
/* from the set type occurrence that contains the record. 7 


disconnect: DISCONNECT record_type FROM 


if (record type’ record is not current record of run unit) 
perform error(3) 
return 

end if 

else 
alloc and init new connect list 

end else 


} 


set type list 


alloc and init ’disconnect’ node 
for (each set type on connect _list) 
if (record type’ is not a member type record for 'set type”) 
perform error(5) 
return 
end if 
else 
alloc and init new abdl str 
copy "(UPDATE ((TEMPLATE = "record type”) and 
(DBKEY = CIT.RUN_UNIT.dbkey)) 
(MEMBER.set_ type = NULL)" 


to abdl str 
connect abdl str to ‘disconnect’ node 
end_else 
end for 
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connect list = NULL /* reset connect list */ 


} 


perform loop: PERFORM UNTIL bb EQ cc 
| END PERFORM 


) 


bb: EOF 
| NOTFOUND 


3 


ce, YES 
NO 


? 





item list: item name 


{ 


put item name on select list 


| item list COMMA item name 


i 


put successive item names on select list 


} 


schema name: IDENTIFIER 


3 


record type: IDENTIFIER 


3 


set type: IDENTIFIER 


) 


item name: IDENTIFIER 


3 
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item value: IDENTIFIER 
| INTEGER 


2 


proc error(err_code) 
/* This procedure prints error messages, causes data structures to */ 
/* be de-allocated, and causes proc yyerror to be executed. a 


case err code of 
1: print("Error - must initialize ’record_type’ record template") 


2: print("Error - °data item’ not defined in *'record _type”") 
3: print("Error - ‘record type’ is not current record of run unit") 
4: print("Error - attempting to modify or store record without 
giving value of ‘data-item’") 
5: print("Error - ‘record type’ record does not belong to ’set_type") 
6: print("Error - record types specified are not the same") 
7: print("Error - "record type” is not current of 'set_type”") 
8: print("Error - "record type’ must be a member record of 'set type”) 
end case 
perform cleanup() /* free data structures */ 
perform yyerror() 
return 
end error; 
proc by application(abdl str) 
if (set_ node nsn_ insert =’a’) /* insertion mode is automatic */ 
concat",<MEMBER.set type,CIT.set type.owner dbkey>" to abdl str 
end if 
else /* insertion mode is manual */ 
concat",<MEMBER.set type, NULL>" to INSERT abdl str 


end else 


end by application; 
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proc by value(abdl str) 


locate data_item node in schema for set_select node item_name 
in set select node record1l 
if (nan_dup flag set) 
get owner record type of set_type from schema 
if (owner record type node not on move list) or 
(data_item not on move list) 
perform error(4) 
return 
end if 
else 
if (set node nsn insert = ’a’) /* automatic insertion ll 
get data item “value from move _list 
copy"[RETRIEVE((TEMPLATE = = owner record type) and 
(item name = ‘item _value’)) (DBKEY)]" to abdl str 
connect new retrieve request to store node 
concat",.< MEMBER. set _type,***>" to INSERT abdl str 
end if 
else /* manual insertion */ 
concat",<MEMBER..set_type,NULL>" to INSERT abdl str 
end else 


end else 
end if /* nan dup flag */ 


end by value; 


proc by structural(abdl str) 


locate data item nose in schema for set_select node item_ name 
in set _select node recordl record type 
if (nan dup flag set) 
get recordl name from set_select node for set_type 
if 'record1” record template node not on move _list) or 
(data item not on move list) 
perform error(4) 
return 
end if 
else 
if (set_ node nsn_ insert = ’a’) /* automatic insertion */ 
get data item value from move ast 
get record2 name from set _ select. node for set_type 
copy"[RETRIEVE ((TEMPLATE = record2 name) and 
(item name = item_value)) (DBKEY)" to abdl_str 
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connect new retrieve request to store node 
concat",< MEMBER.set_type,***>" to INSERT abdl str 
end if 
else /* manual insertion */ 
concat",< MEMBER.set_type,NULL>" to INSERT abd] str 
end else 
end else 
end if /* nan dup flag */ 


end by structural; 


proc by default(abdl str) 


print("Warning - Attempting to store a record with no 
particular set selection given. Will assume *BY 
APPLICATION") 
if (set_node nsn insert = ’a’) /* automatic insertion */ 
concat",< MEMBER. set_type,CIT.set_type.owner_dbkey>" 
to INSERT abdl str 
end if 
else /* manual insertion */ 
concat",<MEMBER.set type,NULL>" to INSERT abdl str 
end else 


end by default; 


proc erase all(record type,erase node) 
string member type; 


for (each set type in schema) 
if (record type’ is owner type of set_type) 
member type = member type of set_type 
/* for RETRIEVE to get members of ’set_ type’ */ 
alloc and init new abdl str 
copy "[RETRIEVE(MEMBER.set type = ***)(DBKEY) by DBKEY|" 
to abdl str 
connect abdl str to erase node 
/* delete member records */ 
alloc and init new abdl str 
copy "[DELETE((TEMPLATE = 'member type”) and (DBKEY = ***))]" 
to abdl str 
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connect abd] str to erase node 
/* erase descendants of member records */ 
erase all(member_ type,erase node) 
end if 
end for 
return(erase node) 


end erase all 
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APPENDIX C - THE KC PROGRAM SPECIFICATIONS 


module KERNEL CONTROLLER() 


/* This procedure accomplishes the following: a 
/* Depending on the dmi operation the corresponding */ 
/* procedure is called. */ 


case (dmi operation) 
CreateDB: 
perform LOAD TABLES(); 
Disconnect: 
Connect 
Modfltem : 
ModfRec 
perform REQUEST HANDLER(); 
FindReq: 
perform FIND REQUESTS HANDLER(); 
StorReq: l 
perform STORE REQUESTS HANDLER(); 
EraReq: 
perform ERASE REQUESTS HANDLER(); 
GetReq: 
perform DML KFS(); 
MoveRea: 


default: 
/* This handles any errors */ 
end case 


end module 
LOAD TABLES() 


/* This procedure accomplishes the following: 
/* (1) Calls dbl template which is already 
/* defined in the Test Interface. It loads the 
/* template file. 

* 


/* (2) Calls dbl dir tbls() also defined in 
/* the Test Interface. It loads the descriptor 
/* files. 


{ 
perform DBL TEMPLATE(); 
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perform DBL DIR TBLS(); 
} 


end proc 
REQUEST HANDLER() 


/* This procedure accomplishes the following: 
/* (1) Calls dml execute untill all CODASYL-DML 
/* queries associated with abdl req data 
/* structures are processed. 
* 
/* (2) If query is Connect or Disconnect, then 
/* appropriate action is taken to update the CIT 
/* table. 


while (! end of request ) 
perform DML EXECUTE(abdl str,file ptr); 
if (operation == Connect) 
{ 
while (connect list != NULL) 
{ 
current set type = run unit record name 
current set dbkey = run unit dbkey 
} 
} 


if (operation == Disconnect) 


while (connect list != NULL) 
{ 

current set type = 
current set dbkey = 0 


} 
} 
} 


end proc 


oa? 


FIND REQUESTS HANDLER() 


/* This procedure accomplishes the following: 
/* Depending on the find operation takes 

/* appropriate action, then set correct 

/* location in the result buffer. 


case (find operation) 
AnyFin: 
perform DML EXECUTE(abdl str,file ptr) 
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if (dont update != TRUE) 
perform Find update() 

First Fin: 
perform DML EXECUTE(abdl str,file ptr) 
locate first record in the result buffer 
create temporary string to hold this record 
current buff val = dbkey value of this record 
increment buffer location 
if (dont update != TRUE) 
perform Find update() 

LastFin: 
perform DML EXECUTE(abdl str,file ptr) 
locate the last record in the result buffer 
create temporary string to hold this record 
current buff val = dbkey value of this record 
if (dont update != TRUE) 
perform Find update() 

NextFin: 
first find correct find node corresponding 
NextFin request 
locate correct result file 
free temporary string 
reload temporary string with the next record value 
current buff val = dbkey value of this record 
increment buffer location 
if (dont update != TRUE) 
perform Find update(} 

PriorF in: 
first find correct find node corresponding 
PriorFin request 
locate correct result file 
open this file to read again 
locate prior record of the current record 
free temporary string 
reload temporary string with this record value 
current buff val = dbkey value of this record 
decrement buffer location 
if (dont update != TRUE) 
perform Find _ update() 

OwnerF in: 
perform DML EXECUTE(abdl str,file ptr) 
create temporary string to hold the result 
if (dont update != TRUE) 
perform Find _update() 

WithinFin: 
perform DML EXECUTE(abdl str,file ptr) 


104 


create temporary string to hold the first record 
current buff val = dbkey value of this record 
increment buffer location 
if (dont update != TRUE) 
perform Find _update() 
CurFin: 
if (dont update != TRUE) 
perform Find update() 
DupFin: 
first find correct find node corresponding 
DupFin request 
locate correct result file 
while (current buffer location <= 
number of result in the result buffer) 
free temporary string 
reload temporary string with this record value 
current buff val = dbkey value of this record 
make comparesion to find duplicate record 
end while 
if (dont_update != TRUE) 
perform Find update() 
end case 


} 


end proc 
FIND UPDATE() 


/* This procedure update the CIT table 
/* depending on request 


initialize currency table pointer 
case (find operation) 
AnyFin: 

locate first record in the result buffer 
create temporary string to hold this record 
if (set list == NULL) 
{ 
set set ptr 
/* determine this record belongs to which set */ 
while (set_ptr != NULL) 
{ 


if (!on suppres list(set_name)) 
if (set_owner_name == record name) 
if (set_name on the CIT table) 
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{ 


current buff val = dbkey value of this record 
current set owner dbkey = current buff val 
current set _dbkey = current buff val 


} 


else 


allocate new cur set node 

current buff val = dbkey value of this record 
current set owner dbkey = current buff val 
current set _dbkey = current buff v val 


} 
} 
} 
get next set ptr 
} 
} 
else 
{ 
set fset_ptr to set_list of AnyFin node 
while (fset_ptr != NULL) 
store dbkey value(s) of owner set(s) to 
correct field of set list structure 
end while 
current bufí val = dbkey value of this record 
while (set list != NULL) 
( 
if (!on _suppres list(set_name)) 


{ 


if (set name on the CIT table ) 


current set owner dbkey = set list dbkey 
current set dbkey = current buff val 


} 


else 


allocate new cur_ set node 
current set owner dbkey = set list dbkey 
current set dbkey = current buff val 


} 
} 


get next set list 


} 


/* update current run unit */ 
run unit record name = rec name of find ptr 
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run unit dbkey = current buff val 


PriorFin: 

FirstFin: 

WithinFin: 

Last Fin: 

NextFin: 
run unit record name = rec_name of find ptr 
run unit dbkey = current buff val 
current set type = rec name of find ptr 
current set dbkey = current buff val 

OwnerfFin: 
run unit _record _Name =current set owner name 
run unit dbkey = current set owner dbkey 
current set type = current set owner_name 
current set dbkey = current set owner dbkey 

CurFin: 
run unit record name = current set type 
run unit dbkey = current set dbkey 


end case 


} 


end proc 
STORE REQUESTS HANDLER() 


/* This procedure executes correct request(s) 


/* and update the CIT table 


perform(DML EXECUTE(abdl str,file ptr) 


if (lresults are not returned) 


print(Error non duplicate attribute(s) have 
values in the database) 
} 


else 


{ 


set member ptr 
while (member ptr != NULL) 


{ 
if (selection mode is by VALUE or by STRUCTURAL) 


if (member ptr->rn_ flag == TRUE) 


get next member ptr 
else if (insertion mode is AUTOMATIC) 


107 


perform DML EXECUTE(abdl str,file ptr) 


if (results are not returned) 


print (Error the owner of the set type does 
not have dbkey value) 
} 


else 


perform BUILD REQUEST(store ptr,member ptr) 


get next member ptr 


} 
} 


else 


: 


else 
} 
if (stored record is a owner record) 
perform BUILD REQUEST(store ptr) 
perform DML EXECUTK(store abdl str,file ptr) 
} /* end else */ 
/* update CIT table */ 
if (dont update != TRUE) 


{ 


run _unit record name = rec name of store ptr 
run unit dbkey = last dbkey -1 
if (stored record is not a owner record) 


while (member ptr != NULL) 


{ 


if (!on suppres list(set_name)) 
if (selection mode is by VALUE or by STRUCTURAL) 


if (insertion mode is AUTOMATIC) 
{ 


if (set name on the CIT table) 


{ 


current set type = run unit record name 

current set dbkey = run_unit dbkey 

if (member ptr->rn flag == TRUE) 
current set owner dbkey = 0 


else 
current set owner dbkey = current_buff_val 


} 
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else 


allocate new cur set node 
current set dbkey = run unit dbkey 
current set owner dbkey = current buff val 


} 
} 


else 


s 


else 


if (insertion mode is AUTOMATIC) 

{ 

current set type = run unit record name 
current set dbkey = run unit dbkey 


} 


else 

} 

} 

get next member ptr 
} 

} 
} 
} 


end proc 
BUILD REQUEST (store ptr,member ptr) 


/* This procedure accomplishes the following: 
/* Builds an abdl INSERT request in the store 
/* template 


{ 


allocate enough space for store template 


if (StorFlag != TRUE) 


fill store template with contents of store abdl req 
'til an *’ is hit 

fill store template with the last dbkey of schema 
increment dbkey value of schema 

skip over the asteriks we just filled with a value 


StorFlag = TRUE 


} 
if ((mem flag != TRUE) || 
selection mode is by APPLICATION || 
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selection mode is by OPTIONAL) 


fill store template with the rest of store abdl req 
tan? 15 hit 
} 


else 


fill store template with contents of store abdl req 
til an ’*’ is hit 

fetch a value from the result file 

put this value into store template 

fill store template with the rest of store abdl req 
tano ° is hit 

} 


copy store template to store abdl req 
end proc 
ERASE REQUESTS HANDLER() 


/* This procedure accomplishes the following: 
/* Depending on the erase operation takes 
/* appropriate action 


if (erase operation == RecEra) 


perform DML_EXECUTE(erase ret str,file ptr) 


if (results are not returned) 


perform DML EXECUTE(erase abdl str,file ptr) 
/* update current run unit */ 

run unit record name =”” 

run_ unit dbkey = 0 


} 


else 


print (Error the record being deleted is an 
owner of a non empty set) 
} 


} 


else 


/* Erase ALL operation */ 
while (member ptr != NULL) 


perform ERASE MEMBER(member ptr) 
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get next member ptr 


perform DML EXECUTE(erase abdl str,file ptr) 
/* update current run unit */ 
run unit record name =’ ’ 
run unit dbkey = 0 
} 
} 


end proc 
ERASE MEMBER(member ptr) 


/* This procedure accomplishes the following: 
/* If the record being deleted is an owner of 
/* other set, we must delete its member record(s) 
{ 
perform DML EXECUTE(member abdl.file ptr) 
open correct buffer file to get a value 
/* This is our stopping condition */ 
while (all elements in the result buffer have been used) 
( 
pass over attribute name (DBKEY) 
current buff val = value of this attribute 
fill member template with contents of member delete req 
lan °™* is hit 
fetch a value from the result file 
put this value into member template 
fill member template with the rest of member _delete req 
til an ° ’ is hit 
If (this member record being deleted is an 
owner of other set) 
{ 


complete retrieve request using current buff val 


perform ERASE MEMBER(member ptr) 


perform DML EXECUTE(member template,file ptr) 


increment buffer location 


} 
perform free cur set(set_name) 


} 


end proc 
FREE CUR SET(set_name) 


/* This procedure accomplishes the following: 
/* Frees given set type on the CIT table 
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{ 


initialize currency set ptr 
current flag = FALSE 
while ((set_ptr != NULL) && (current flag == FALSE)) 


if (set_ ptr->name == set name) 


free(set_ptr) 
current flag = TRUE 


if (current flag != TRUE) 
get next set ptr 

} 

} 


end proc 
DML EXECUTE(string,file ptr) 


/* This procedure accomplishes the following: 
/* (1) Sends the request to MBDS using 
/* TI S$TrafUnit() which is defined in the Test 
/* Interface 

x 
/* (2) Calls dml check requests left() to ensure 
/* that all requests have been received 


perform TI S$TrafUnit(string) 
perform dml check requests left(file ptr) 


} 


end proc 
DML CHECK REQUESTS LEFT (file ptr) 


/* This procedure accomplishes the following: 
/* (1) Receives the message from MBDS by calling 
/* TI _RéMessage() which is defined in the Test 
/* Interface 
* 
/* (2) Gets the message type by calling 
¡* TI R3Type 
* 


/* (3) If not all the responses to the request 

/* have been returned, a loop is entered. Within 
/* this loop a case statement separates the 

/* responses received by message type 


D 
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/* (4) If the response contained no errors, 

/* then procedure TI R$Req res() is called to 
/* receive the response from MBDS 

p* 

* (5) If no results are returned, then 
/* the boolean results are not returned is set 
/* to TRUE 

* 

/* (6) If the message contained an error, 

* then procedure TI R$ErrorMessage is called 
/* to get the error message and then procedure 
/* TI _ErrRes output is called to output the 
/* error message 
{ 
results are not returned = FALSE 
done = FALSE 
while ( !done) 


TI R$Message() 

msg type = TI R$Type() 

case (msg type) 

CH ReqRes: 
done = TI R$Req _res(&rid,response) 
if (string length of (response) == 0) 
results are not returned = TRUE 

else 


t = file results(file ptr) 
if ( t > max length of previous results ). 
max length = t 


Reqs WithErr: 
/* handle error conditions */ 
} 


} 


end proc 
FILE RESULTS (file ptr) 


/* This procedure accomplishes the following: 
/* (1) Opens a file to place the results in 
x 


/* (2) Keep track of how many results have 


/* been received 
i 


/* (3) Puts the results in their own line 
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ie 


/* (4) Returns the length of the response 


/* Next two statements are initialization */ 

initialize buff loc 

initialize num values 

/* If this is the first time then we open 
file for write status */ 

if (file ptr->nfi status == FIRSTTIME) 

{ 

perform init_buffer() 

open file for write mode 

set nfi status to RESTTIME 

buff loc = buff loc + 1 

} 

else 

open file for append status 

res len = string length of (response) 

curr pos = 1 

/* Read first attribute from response */ 

read dml response(first attr,curr pos) 


/* Put this attribute in buffer */ 
put in buff(first attr) 


/* Read the value corresponding to this attribute */ 
read dml response(temp str,curr pos) 


/* Put this value in the buffer */. 
put in buff(temp str) 
save max = curr pos 


/* Increment the count of values */ 
num values = num values + 1 


/* While we are not at the end of the response */ 

while (curr _pos < (res len - 2)) 

{ . 

read dml response(temp str,curr pos) 

/* If the attribute name just read in is not the same 
as the first attribute name proviously read in, 
then we put it and its value on the same line in 
the buffer as the first attribute */ 

1£ (first attr != temp str) 


{ 


put in buff(temp str) 
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read dml response(temp_str,curr_pos) 
put in buff(temp str) 

max char = curr pos 

max char2 = max char - cur length 
if (max char2 > save max) 

save max = max char2 


/* If they are the same, then we need to start a new 
line in the buffer */ 
else 
{ 
cur length = curr_pos - val len 
put in buff("0) 
put in buff(temp str) 
read dml response(temp str,curr_pos) 
put in buff(temp str) 
num values = num values + 1 


} 


close file 
open file 
return(save max) 


} 


end proc 
DML KF S() 


/* This procedure accomplishes the following: 
/* Pulls all attributes or some specific 

/* attribute(s) of a record and displays 

/* it to the user 

{ 

first find correct get node 

if (get operation == Getltem) 


while (1 <= number of attributes of this record) 


pull specific attributes and its values from 
temp str of net file info structure 
display them to the user 


} 
} 


else 


while (i <= number Of attributes of this record) 
display temp str to the user 
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} 
} 


end proc 
PUT IN BUFF(string) 


/* This procedure accomplishes the following: 
/* Puts the incoming string form file results 
/* into the correct file buffer 


end proc 
INIT BUFFER() 


/* This procedure accomplishes the following: 
/* (1) Copies the user’s ID name into a temp 
/* string 

* 


/* (2) Converts the current dmi buff count to 


/* a string 
* 


/* (3) Increments the above count to reflect 
/* the fact that the next time this procedure 
/* is called it initialize a new buffer 


ie 


/* (4) strcat above count to temp 

/* (5) streat BUFF FILE SUFFIX to temp 
/* (6) strepy temp over to nfi_buff.fi_ fname 
end_proc 

READ DML RESPONSE(outstr,pos) 


/* This procedure accomplishes the following: 
/* Reads the next value of the response buffer 


load outstr with the contents of response until 
an End Marker is detected 
put a’’ in outstr 


} 


end_proc 
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ON SUPPRES LIST(set name) 


/* This procedure accomplishes the following: 
/* Checks the given set on the suppres list or not 
{ 
/* set correct supp ptr */ 
if (dmi_ operation == FindReq) 
set supp ptr 
else 
set supp ptr 
while (supp ptr != NULL) 


if (supp _ptr->set_ name == set name) 
return(TRUE) 
get next supp ptr 


} 
return(FALSE) 


} 


end proc 
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APPENDIX D - THE CODASYL-DML USERS’ MANUAL 


A. OVERVIEW 


The CODASYL-DML language interface allows the user to input 
transactions from either a file or the terminal. A transaction may take the form 
of either database descriptions of a new database, or CODASYL-DML requests 
against an existing database. Database descriptions may only be input from a 
file, while CODASYL-DML requests may be input from either a file or the 
terminal. The CODASYL-DML language interface is menu-driven. When the 
transactions are read from either a file or the terminal, they are stored in the 
interface. If the transactions are database descriptions, they are executed 
automatically by the system. If the transactions are CODASYL-DML requests, 
the user is prompted by another menu to selectively choose an individual 
CODASYL-DML request to be processed. The menus provide an easy and 
efficient way to allow the user to view and select the methods in which to process 
CODASYL-DML transactions. Each menu is tied to its predecessor, so that by 
exiting each menu the user is moved up the "menu tree". This allows the user to 


perform multiple tasks in a single session. 
B. USING THE SYSTEM 


There are two operations the user may perform. The user may either define 
a new database or process requests against an existing database. The first menu 
displayed prompts the user for an operation to perform. This menu, hereafter 


referred to as MENU1, looks like the following: 


Enter type of operation desired 
(1) - load a new database 
(p) - process old database 
(x) - return to the operating system 


ACTON = J 
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Upon selecting the desired operation, the user is prompted to enter the name 
of the database to be used. When loading a new database, the database name 
provided may not presently exist in the database schema. Likewise, when 
processing requests against an existing database, the database name provided has 
to exist in the present database schema. In either case, if an error occurs, the 
user is told to rekey a different name. The session continues once a valid name is 
entered. 

If the "p" operation is selected from MENU1, a second menu is displayed 
that asks for the mode of input. This input may come from a data file or 
interactively from the terminal. This generic menu, MENU2, looks like the 


following: 


Enter mode of input desired 
(f) - read in a group of transactions from a file 
(t) - read in transactions from the termina] 
(x) - return to the previous menu 


MOTION => 


If users wish to read transactions from a file, they are prompted to provide the 
name of the file that contains those transactions. If users wish to enter 
transactions directly from the terminal, a message is displayed reminding them of 
the correct format and special characters that are to be used. 

If the "l" operation is selected from MENU1, a second menu is displayed that 
is identical to MENU2 except that the "t" option is omitted. Since the 
transaction list stores both database descriptions and CODASYL-DML requests, 
two different access methods have to be employed to send the two types of 
transactions to the KMS. Therefore, our discussion branches to handle the two 
processes the user may encounter. 


1. Processing Database Descriptions 


When the user has specified the filename of the schema, further user 
intervention is not required. It does not make sense to process only a single 
schema definition statement out of a set of schema definition statements that 
produce a new database, since they all have to be processed at once and in a 


specific order. Therefore, the mode of input is limited to files, and the 
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transaction list of schema definition statements is automatically executed by the 
system. Since all the schema definition statements have to be sent at once to 
form a new database, control should not return to MENU2 where further 
transactions may be input. Instead, control returns to MENU1 where the user 
may select a new operation or a new database to process against. 


2. Processing CODASYL-DML Requests 


In this case, after users have specified the mode of input, they conduct an 
interactive session with the system. First, all CODASYL-DML requests are 
listed to the screen. As the CODASYL-DML requests are listed from the 
transaction list, a number is assigned to each CODASYL-DML request in 
ascending order starting with the number one. The number is printed on the 
screen beside the first line of each CODASYL-DML request. Next, an access 
menu, called MENU3, is displayed which looks like the following: 


Pick the number or letter of the action desired 
(num) - execute one of the preceding CODASYL-DML requests 
(d) - redisplay the list of CODASYL-DML requests 


(x) -return to the previous menu 


ACTION 


Since the displayed CODASYL-DML requests may exceed the vertical 
height of the screen, only a full screen of CODASYL-DML requests are displayed 
at one time. If the desired CODASYL-DML request is not displayed on the 
current page, the user may depress the RETURN key to display the next page of 
CODASYL-DML requests. If the user only desires to display a certain number of 
lines, after the first page is displayed the user may enter a number, and only that 
many lines of CODASYL-DML requests are displayed. If users are only looking 
for certain CODASYL-DML requests, once they have found them, they do not 
have to page through the entire transaction list. By depressing the "q" key, 
control is broken from listing CODASYL-DML requests, and MENU3 is 
displayed. Under normal conditions, when the end of the transaction list has 


been viewed, MENU3 appears. 
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Since CODASYL-DML requests are independent items, the order in 
which they are processed does not matter. The users have the choice of 
executing however many CODASYL-DML requests they desire. A loop causes 
the transaction list and MENU3 to be redisplayed after each CODASYL-DML 
request has been executed so that further choices may be made. Unlike 
processing the schema definition, control returns to MENU2 since the user may 
have more than one file of CODASYL-DML requests against a particular 
database, or the user may wish to input some extra CODASYL-DML requests 
directly from the terminal. Once the user is finished processing on this particular 
database, the user may exit back to MENUL to either change operations or exit 


to the operating system. 
C. DATA FORMAT 


When reading transactions from a file or the terminal, there has to be some 
way of distinguishing when one transaction ends and the next begins. 
Transactions are allowed to span multiple lines, as evidenced by a typical multi- 
level MOVE statements followed by a STORE statement. This example also 
shows that our definition of transaction incorporates one or more requests. This 
allows a group of logically related requests to be executed as a group. Since the 
system is reading the input line by line, an end-of-transaction flag is required. In 
our system this flag is the "Q" -character. TS the system needs to know 
when the end of the input stream has been reached. In our system the end-of-file 
flag is represented by the "$" character. The following is an example of an input 
stream with the necessary flags that are required when multiple transactions are 


entered: 
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D. RESULTS 


TRANSACTION #1 
@ 

TRANSACTION #2 
REQUEST #1 
REQUEST #2 


REQUEST #n 

a 

TRANSACTION 43 
a 


a 
TRANSACTION ¿n 
$ 


When the results of the executed transactions are sent back to the user's 


screen, they are displayed exactly the same way individual CODASYL-DML 


requests are displayed. The following consolidates the user's options: 


KEY 
return 
(number) 


q 


FUNCTION 

Displays next screenful of output 
Displays only (number) lines of output 
Stops output, MENU1 is then redisplayed 
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10. 
11. 


12. 
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